A module with `go 1.21` in go.mod is built by Go 1.25 — does `for i := 0; i < 3; i++ { go func() { fmt.Println(i) }() }` share one `i`?

## Why a compiler upgrade did not change this program The question puts two versions on the table and they do different jobs: - **Go 1.25** is the release performing the build. Its only requirement is to be at least as new as the module's go line. - **`go 1.21`** in go.mod is the module's **language version**. It decides which language rules the compiler applies to these files. Per-iteration loop variables are a **language** change, introduced in **Go 1.22**. Like every language change since modules gained a language version, it is gated on the go line. So a module that declares `go 1.21` is compiled under Go 1.21 rules: the three-clause `for` statement declares one `i` that the whole loop reuses, every function literal closes over that one variable, and building with a Go 1.25 or Go 1.27 install does not alter that by one bit. ### Why the gate exists at all This is the clearest example in the language of why per-module gating was worth building. Changing what a loop variable *is* changes the meaning of programs that already compile and already pass their tests, silently and without any error message. If that change had arrived with the compiler, every team's next toolchain upgrade would have been a semantic migration of all their code at once, with no diff to review. Gating it on the go line inverts that. The compiler upgrade is boring and reversible; the semantic change happens in a one-line commit to go.mod that a reviewer can see, that lands on a date the team chose, and that can be reverted independently of which compiler the CI image ships. ### What actually flips it One edit: ``` go 1.22 ``` After that, the module's files are compiled under Go 1.22 rules and each iteration gets its own `i`. Nothing else — not the installed release, not a build flag you should be reaching for, not clearing the build cache — changes the answer. `go mod edit -go=1.22` performs the edit for you. Because the language version is per module, the effect is neatly scoped: raising your go line changes your module's loops, and leaves every dependency compiling under its own recorded go line. A `go 1.19` library in your build list keeps 1.19 loop semantics inside its own files even while your module runs at 1.22. ### What the goroutines actually print Do not assert an output. With a single shared `i` the three goroutines all read the same variable, and whether they observe 0, 1, 2 or 3 depends entirely on when the goroutine scheduler runs them relative to the loop; concurrent reads of a variable the loop is still writing are also a data race, which `go build -race` will report. The point of the question is not the printed digits — it is which of the two version numbers on the table controls the semantics. ### How to check the version a module is really compiled at Read go.mod. That is the answer for the main module, and `go list -m -f '{{.Path}} {{.GoVersion}}' all` prints the recorded go line for every module in the build list when you want to reason about a dependency's files instead of your own. The Go release you happen to have installed is reported separately by `go version`, and comparing the two is exactly the muscle this question is testing.