3 ms·

I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. But regardless, let

I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. But regardless, let’s say it’s a bad PR for the sake of argument - it’s beside the point. It cannot be merged no matter how good it is, due to the strict no-LLM policy.

greggyb 6mo ago
> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs. I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.
- daishi55 6mo ago
  Do you think they skipped the main zig test suite or something? Only tested bun compilation? That seems unlikely to me
  - thunderfork 6mo ago
    They didn't take into account the long-run impacts of the changes on future development, etc. I recommend reading the explanation given by one of the Zig devs, as it's a very clear and solid one.
    - zeroonetwothree 6mo ago
      This is the most common issue I see with LLM authored PRs. Yes it does fix the issue _right now_ but as a maintainer I need to consider how it affects the project in the future. But “contributors” get mad if you reject for those reasons. So I can understand having a blanket policy.
moregrist 6mo ago
> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. The PR is probably fine for bun’s purposes. That doesn’t make it a good PR for Zig’s purposes, and could very well paint Zig into a weird corner. > It cannot be merged no matter how good it is, due to the strict no-LLM policy. This is about meta-discourse. Of course it’s against the policy. That’s the point of discussing the PR: to get Zig to change the policy, or at least provide an exception in this case. Or to argue the opposite.

greggyb 6mo ago

> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs. I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.

daishi55 6mo ago
Do you think they skipped the main zig test suite or something? Only tested bun compilation? That seems unlikely to me
- thunderfork 6mo ago
  They didn't take into account the long-run impacts of the changes on future development, etc. I recommend reading the explanation given by one of the Zig devs, as it's a very clear and solid one.
  - zeroonetwothree 6mo ago
    This is the most common issue I see with LLM authored PRs. Yes it does fix the issue _right now_ but as a maintainer I need to consider how it affects the project in the future. But “contributors” get mad if you reject for those reasons. So I can understand having a blanket policy.

moregrist 6mo ago

> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. The PR is probably fine for bun’s purposes. That doesn’t make it a good PR for Zig’s purposes, and could very well paint Zig into a weird corner. > It cannot be merged no matter how good it is, due to the strict no-LLM policy. This is about meta-discourse. Of course it’s against the policy. That’s the point of discussing the PR: to get Zig to change the policy, or at least provide an exception in this case. Or to argue the opposite.