> It communicates hostility and disbelief rather than curiosity. To me, it just asks for examples. I guess that's a matter of opinion then. > https://github.

> It communicates hostility and disbelief rather than curiosity. To me, it just asks for examples. I guess that's a matter of opinion then. > https://github.com/golang/go/issues/60078 https://github.com/golang/go/issues/60078 is where this is discussed. We can discuss semantics here, but a breaking change, to me, is one that that breaks well-crafted existing code. Well, what kind of real world code would rely on the fact that closures over an iteration target examine a value that depends on runtime behavior instead of the actual value that, semantically, seems to have been closed over? I have stumbled upon this issue myself when I first learned Go. I have used Go professionally and in private projects and since long before modfiles became a thing. I have NEVER seen code that relies on this completely unintuitive behavior. This is not a change that breaks something good, this is a fix that removes a footgun from the language. Further down, rsc writes this (https://github.com/golang/go/issues/60078#issuecomment-1542432441 https://github.com/golang/go/issues/60078#issuecomment-15424...) That's some of the real-world evidence in favor of changing 3-clause loops. I have looked, and I found no evidence in favor of not changing them. If you want to make the case for not changing them, the way to do that would be to provide real-world examples of code that breaks with the new semantics. So, semantics aside, no, I do not consider this a breaking change, because while it is, technically, not backward compatible, it doesn't break existing code. > I gave multiple examples already. What exactly breaks in the archive/tar package? I looked it up, only found some bugs and issues, but nothing I would consider a change that breaks existing code. What exactly did modfiles break? I can still compile code without modules. Yes, modern versions of the go-tool require a flag via envvars, but they are still compatible with old projects. And libraries changing is not the same as the language changing. If a build relies on a certain commit on the library, I can always check out that commit.