[bccdee]

for-loop variable capture was maybe the #1 worst decision in the language. It was never what you wanted. I appreciate Go's commitment to backwards-compatibility, but in this case breaking it was the right choice.

[tapirl]

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.

[bccdee]

All 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]

This 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.