4 ms·
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-in-go-1.22.html https
by tapirl 8mo ago
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-in-go-1.22.html https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... carefully, it is hard to think it is right.
- bccdee 8mo agoAll the examples in that article are very exotic. 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?
- tapirl 8mo agoThis one is just an example to demo one case of backward-capability breaking. > 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.