Currently (Go 1.24), the official team has not published a tool to identify all of the breaking cases caused by this change. So you might need to check the code by your eyes.
I'm not sure you can actually break code with the new for-loop semantics (I mean, in real life situations). It can probably fix some buggy code in the wild, but I have a hard time believing anyone would voluntarily write code relying on the old semantics of loop variables being reassigned instead of reinitialized.
> I'm not sure you can actually break code with the new for-loop semantics (I mean, in real life situations).
The linked issue thread provides real life cases.
> It can probably fix some buggy code in the wild, but I have a hard time believing anyone would voluntarily write code relying on the old semantics of loop variables being reassigned instead of reinitialized.
For "for-range" loops, you might be correct. However, for 3-clause-for loops, your opinions lack substantial evidence to support them.
> Honestly I think this is a non-issue.
You can think anything. But the facts are there. There are at least 3 important facts of the semantic change on 3-clause-for loops:
1. The new semantics of 3-clause-for loops are more error prone for concurrency programming.
2. The new semantics of 3-clause-for loops may silently downgrade Go code performance.
3. The expected benefits of the change are actually so minuscule that they can be disregarded. On the other hand, the drawbacks of the change are huge.
Honestly I think this is a non-issue.