3 ms·
There's a second motivation in my opinion. Code might work today without the change, but it could be because the author originally wrote buggy code, caught it i
by jjnoakes 3y ago
There's a second motivation in my opinion. Code might work today without the change, but it could be because the author originally wrote buggy code, caught it in testing, and had to waste time tracking it down and understanding nuances that don't need to be there. Once they figured that out, they implemented an ugly workaround (adding an extra function parameter to a goroutine or shadowing the loop variable with n := n).
Good language designers want to avoid both wasting developer's time and requiring ugly workarounds. Making a change that does both, especially if it doesn't break old code, is great imo.
- kazinator 3y agoWhichever way you implement the semantics of the loop variable, the developer has to understand the nuances, don't you think? And those nuances have to be there; all you can do is replace them with other nuances. If a fresh variable i is bound for each iteration, then an i++ statement in the body will not have the intended effect of generating an extra increment that skips an iteration. If you want the other semantics, whichever one that is, the workaround is ugly.
- jjnoakes 3y agoI think you can choose nuances that minimize unexpected behavior in practice, and I think the go team did a good job here.