[1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
[1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
For 3-clause-for loops, if you have read https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... carefully, it is hard to think it is right.
for i, p := 0, (*int)(nil); p == nil; fmt.Println(p == &i) {
p = &i
}
Be honest, how many times have you actually seen code which depended on the address of a variable declared in a 3-clause for-loop remaining stable across loop iterations? Nobody does this. It's extremely weird and un-idiomaic. Heck, 3-clause for-loops are somewhat uncommon in and of themselves. Conversely, everyone who writes Go has experienced unintuitive capture issues with for-range loops.Are you actually aware of any breakages this change has caused?
> All the examples in that article are very exotic.
Have you carefully read that article? All? You must be kidding. The article shows several cases used in practice.
C++ did it so egregiously & disastrously you'd think language maintainers would have been scared straight. No, like moths to a flame, it is the preferred hill to die on.
This is how C99 keeps winning when it bleeping should not. It's settled science, however imperfect. It's not getting rearranged because someone read a blog post. It has stability in real-world clock-on-the-wall terms like nothing else.