A `for (let i = 0; i < 3; i++)` loop declares the variable only once in its head, yet each iteration behaves as if it has its own `i`. How does JavaScript produce that, and which iteration's binding does the `i++` update?

## The puzzle inside the fix Everyone learns that `let` fixes the loop-capture bug. The interesting question is *how*, because the head declares `i` exactly once and the loop clearly keeps counting across iterations. If each iteration had a genuinely independent variable, the counter could never advance. ## The per-iteration environment An *environment* is the runtime record holding a scope's bindings. Normally one block equals one environment. A `for` statement with a lexical head (`let`, or `const` in a `for...of`) is special-cased: the specification's loop evaluation creates a **new environment for each iteration**, and copies the values of the head's bindings from the previous iteration's environment into the new one before continuing. The ordering is the part worth memorising: 1. The head's declaration is evaluated once, creating iteration environment #0 with `i = 0`. 2. The condition is tested, the body runs in that environment. 3. A **new** environment is created and the current value of `i` is copied into it. 4. The **increment runs in the new environment**, then the condition is tested there, then the body runs there. 5. Repeat. So the write performed by `i++` lands on the incoming iteration's copy. The binding that the just-finished iteration's closures captured is never assigned again — it is effectively frozen at that iteration's value, which is precisely why deferred callbacks see 0, 1, 2: ```js const fns = []; for (let i = 0; i < 3; i++) fns.push(() => i); console.log(fns.map(f => f())); // [0, 1, 2] ``` ## They are separate slots, not separate counters Because each iteration's value is copied forward, mutating `i` in the body still steers the loop: ```js for (let i = 0; i < 5; i++) { if (i === 1) i = 3; console.log(i); } // 0, 3, 4 ``` The assignment writes to the current iteration's binding; that value is then copied into the next environment, where the increment turns 3 into 4. Separate bindings do not mean isolated iterations — they mean that once an iteration ends, nothing can retroactively change what its closures observe. ## Where the copy does and does not happen - `for (let i = 0; ...)` — per-iteration binding, copied forward as described. - `for (const x of iterable)` and `for (let x of iterable)` — a fresh binding per iteration too, initialised from the iterator rather than copied. `const` is fine here because nothing assigns to `x` after initialisation. - `for (const i = 0; i < 3; i++)` — this is not a way to be extra safe: the first `i++` throws `TypeError: Assignment to constant variable`. - `while (cond) { let x = ...; }` — the block creates a fresh `x` each pass, because entering a block creates a new environment for its lexical declarations. The special copy-forward rule is only about the *head* of a `for` statement. - `for (var i = 0; ...)` — no per-iteration environment at all; one function-scoped binding for the whole loop. ## Reasoning about it without the spec text A practical mental model: with `let`, the loop body behaves as if it were a function called once per iteration with the counter as a parameter, and the counter value is threaded from one call to the next. That model predicts both observable behaviours — closures see their own iteration's value, and assigning to the counter still influences the next iteration. ## Why the design is the way it is Making the head binding per-iteration is what allows `let` to be a drop-in replacement for `var` in existing loops: control flow is unchanged, only the identity of the captured slot differs. Had the committee made each iteration's variable independent, ordinary counting loops would have broken; had they kept one binding, `let` would not have fixed the capture bug at all. The copy-forward step is the compromise that buys both.