[zadwang]

If I understand correctly the fix requires the new code to add a line in go.mod to use the new behavior. This is about the same as adding x:=x in the loop, and more hidden. Not good.

The alternative can be that whenever address of iteration variable is used inside the loop the variable is per iteration and otherwise it is per loop. This way it is not breaking the old code and have new semantics.

[zimpenfish]

> whenever address of iteration variable is used

That wouldn't fix the closure problem where the address isn't taken.

[zadwang]

You are right.

Would it be possible to add closure use as another case?

[zimpenfish]

I guess you could but now you have to special-cases that need static analysis and all that jazz. Probably easier to just put it behind a version flag.

[viraptor]

> This is about the same as adding x:=x in the loop

It's one per module though. In large enough modules you'll have tens of x:=x though. I assume this also opens the option of doing more such changes through the same system in the future.

[zadwang]

Correct.

The “static analysis” section says that it is impossible to catch all cases where address is used which is true. However if the analysis checks for whether address is TAKEN, then it is trivial. I would like to propose that as an alternative- whenever address is taken the variable is per iteration. Otherwise per loop.

This seems the simplest and logical modification.

[masklinn]

And assuming new projects get the new mod by default, it also makes the langage default-safe, as opposed to requiring the cognitive overhead of evaluating individual loops, or requiring this nonsense as explicit prolog to every loop.