> So the fact that, in Go, one might rely on automatic promotion of an induction variable (which obviously gets mutated every iteration!) to the heap, and thus

> So the fact that, in Go, one might rely on automatic promotion of an induction variable (which obviously gets mutated every iteration!) to the heap, and thus get confused about precisely which value is promoted to the heap, seems weird from my perspective. Automatic promotion is not that big of a factor, fundamentally this is a common issue with closures over mutable bindings, similar issues can be observed in other langages. Most (but not all) have mitigations already because it’s such a common issue especially around loops e.g. C# breaking-changed the semantics of range loops in 5.0, javascript added “let” and “const” which have block and per-iteration scoping, … C, C++, and Rust don’t suffer from it (ish) because one doesn’t have closures and the other two require more explicit management of the capture and its lifetime. C++ could have something similar with capture by reference but the code would probably not be straightforward, and the more straightforward code would have much bigger issues of dangling references.