Why did closures created in a Go for loop all observe the last iteration's value before Go 1.22?

## The symptom A scheduler daemon walks a queue of retry attempts and registers one callback per attempt: ```go var jobs []func() for _, attempt := range attempts { jobs = append(jobs, func() { log.Println("retrying", attempt) }) } ``` Run the jobs later and, on Go 1.21 or earlier, every single log line names the *last* attempt in the queue. Not one line per attempt — the same value, repeated. This is the single most reported Go surprise, and the diagnostic is exactly that log: identical output from callbacks you know were built from different data. ## The mechanism Two facts combine. **Fact one: a function literal captures the variable, not its value.** The literal above does not copy `attempt` when it is created. It holds a reference to whatever variable `attempt` names, and it reads that variable when it runs. **Fact two (pre-1.22): the loop declared its variables once.** In `for _, attempt := range attempts`, `attempt` was one variable belonging to the whole loop statement. Each iteration assigned the next element into it. So all N literals captured the same single variable. By the time anything called them, the loop had finished and that variable held the final element. Nothing about `append`, about slices, or about goroutines is involved. The example above is completely sequential and deterministic. Concurrency merely makes the bug louder, because a goroutine version prints the last value repeatedly *and* nondeterministically. ## The pre-1.22 fixes Both work by creating a new variable per iteration, which is the only thing that helps: ```go for _, attempt := range attempts { attempt := attempt // a fresh variable, scoped to this iteration jobs = append(jobs, func() { log.Println("retrying", attempt) }) } ``` The shadowing line `attempt := attempt` declares a new variable inside the body, initialised from the loop's variable. The literal captures the new one, which is never reassigned. The alternative is to pass the value in: ```go for _, attempt := range attempts { jobs = append(jobs, makeJob(attempt)) } ``` Here `makeJob`'s parameter is the fresh per-call variable. Same principle, better readability, because the capture is now visible in a signature. ## What Go 1.22 changed Go 1.22 changed the language: variables declared by a `for` statement are now created anew on each iteration, for both range loops and three-clause loops. The example at the top now logs each attempt exactly once, with no shadowing line. For a three-clause loop such as `for i := 0; i < n; i++`, each iteration still gets its own `i`; the iteration's variable is initialised from the previous iteration's final value before the post statement runs, so the loop counts exactly as it always did — only the identity of the variable a closure grabs has changed. The change is gated on the language version a package is compiled at, so a module that has not moved its version line keeps the old, shared-variable behaviour. That is why the same source file can behave differently in two repositories, and it is the first thing to check when a colleague cannot reproduce your result. ## Why this was safe to change Go's compatibility promise usually forbids changing the meaning of existing programs. This one went through because the old semantics were essentially always a bug when observed: a program that could tell the difference was a program capturing the loop variable, and virtually all of those were wrong. The Go team measured the fallout and shipped it behind the per-package language version so nothing changed under an unmodified module. ## Tooling `go vet` carries a `loopclosure` analyzer, but it never covered this fully: it reports the classic shapes — a function literal referencing the loop variable as the last statement of a loop body, launched with `go` or `defer` — and cannot see a closure you append to a slice or hand to a registration API. Do not treat a clean vet run on an older module as evidence that no closure captures a shared loop variable. ## What to say in an interview Name the two facts (capture is by variable; the loop used to have one variable), show the symptom, give the shadowing fix, and then state the 1.22 change *with its gating*. Candidates who say only 'Go fixed that in 1.22' miss the half that matters when you maintain a codebase spanning several module versions. ## Related traps that are not this one A closure over a variable declared *outside* the loop is still shared, in every version of Go — 1.22 changed only variables declared by the `for` statement itself. And ranging over a slice hands the body a copy of each element, so mutating the loop variable never writes through to the slice; that is a different rule and it is unchanged.