It is only right for for-each loops.
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 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.