2 ms·

> What a terrible comment. How is asking for examples for a statement a "terrible comment"? >go is changing the loop semantics to scope loop variables to the

> What a terrible comment. How is asking for examples for a statement a "terrible comment"? >go is changing the loop semantics to scope loop variables to the loop. Now, I like and agree with this change, but it is a breaking change. Please explain what exactly that change breaks. > Behavior changes that are only apparent at runtime is where go makes breaking changes. Such as? And yes, I am asking for examples. Because I have personally compiled and run code that was written in Go 1.8, with a modern compiler. And the only change I saw so far, is better performance.

cpuguy83 3y ago
> How is asking for examples for a statement a "terrible comment"? Demanding 10 examples is a terrible comment. It communicates hostility and disbelief rather than curiosity. > Please explain what exactly that change breaks. https://github.com/golang/go/issues/60078 https://github.com/golang/go/issues/60078 is where this is discussed. Again, I _agree_ with this change, but I'm pointing out that it is a breaking change. rsc points out in the proposal that it is a breaking change. > Such as? And yes, I am asking for examples. Because I have personally compiled and run code that was written in Go 1.8, with a modern compiler. And the only change I saw so far, is better performance. I gave multiple examples already. If you are truly interested I'm sure you can find more either in the go issue tracker or on google.
- saturn_vk 3y ago
  > Demanding 10 examples is a terrible comment. It communicates hostility and disbelief rather than curiosity. It followed the same tone of your comment, where you claimed that they were doing frequent changes, without providing any examples, of which there should be numerous, if they really occur so frequently.
- usrbinbash 3y ago
  > 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.

cpuguy83 3y ago

> How is asking for examples for a statement a "terrible comment"? Demanding 10 examples is a terrible comment. It communicates hostility and disbelief rather than curiosity. > Please explain what exactly that change breaks. https://github.com/golang/go/issues/60078 https://github.com/golang/go/issues/60078 is where this is discussed. Again, I _agree_ with this change, but I'm pointing out that it is a breaking change. rsc points out in the proposal that it is a breaking change. > Such as? And yes, I am asking for examples. Because I have personally compiled and run code that was written in Go 1.8, with a modern compiler. And the only change I saw so far, is better performance. I gave multiple examples already. If you are truly interested I'm sure you can find more either in the go issue tracker or on google.

saturn_vk 3y ago
> Demanding 10 examples is a terrible comment. It communicates hostility and disbelief rather than curiosity. It followed the same tone of your comment, where you claimed that they were doing frequent changes, without providing any examples, of which there should be numerous, if they really occur so frequently.
usrbinbash 3y ago
> 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.