Before `let` existed, how did you make `for (var i = 0; i < 3; i++) setTimeout(function () { console.log(i); }, 0);` log 0, 1, 2 without changing `var`? Show the wrapper and say what actually makes it work.

## Why a wrapper is needed at all With `var` there is exactly one binding for the counter, shared by every function created in the loop, and every deferred callback reads it after the loop has finished. To fix it without changing the declaration you must give each iteration a **different binding that holds a copy of the value at that moment**. Everything below is a way to manufacture such a binding. ## The IIFE with a parameter ```js for (var i = 0; i < 3; i++) { (function (n) { setTimeout(function () { console.log(n); }, 0); })(i); } // 0, 1, 2 ``` Calling a function creates a new environment for that call, containing its parameters. `n` is a fresh binding per invocation, initialised by copying the argument's value — and for a number, copying the value is all there is. The timer callback closes over `n`, which nothing ever reassigns, so it reports that iteration's number. The most common mistake is dropping the parameter: ```js for (var i = 0; i < 3; i++) { (function () { setTimeout(function () { console.log(i); }, 0); // still 3, 3, 3 })(); } ``` The wrapper runs, a new environment is created — but nothing in it is named `i`, so the lookup walks out to the same shared `var` binding. Calling a function is not what fixes the bug; **passing the value as an argument** is. The same trap appears when the parameter exists but the inner function reads `i` instead of `n`. ## bind, which freezes arguments `Function.prototype.bind` returns a new function with `this` and any leading arguments fixed at bind time: ```js for (var i = 0; i < 3; i++) { setTimeout(console.log.bind(null, i), 0); } // 0, 1, 2 ``` The value of `i` is read when `bind` is called — during that iteration — and stored inside the bound function. Later mutation of the outer binding is irrelevant because nothing looks it up again. This form is compact, but it forces the callback to be a function you can bind arguments onto, which does not always fit. ## Argument forwarding Timers forward any arguments after the delay to the callback: ```js for (var i = 0; i < 3; i++) { setTimeout(function (n) { console.log(n); }, 0, i); } // 0, 1, 2 ``` Same mechanism as the IIFE — a parameter binding created per call, initialised from a value read at scheduling time — with the function call supplied by the timer instead of written by hand. ## The modern equivalents Both of these are what you would actually write today: ```js for (let i = 0; i < 3; i++) setTimeout(() => console.log(i), 0); // per-iteration head binding for (var i = 0; i < 3; i++) { const n = i; // fresh block binding per pass setTimeout(() => console.log(n), 0); } ``` The `const` copy is worth knowing even in modern code: it is the fix when the counter must stay `var` (say, because something after the loop reads it), and it is the same idea as the IIFE parameter with none of the extra function. ## The important caveat: copying a reference is not copying data All of these copy a **value**. If the value is an object reference, every iteration's binding still points at the same object, and mutating that object later is visible through all of them: ```js var cfg = { id: 0 }; for (var i = 0; i < 3; i++) { (function (c) { setTimeout(function () { console.log(c.id); }, 0); })(cfg); cfg.id = i; } // 2, 2, 2 — one object, three references to it ``` The wrapper did its job; the problem moved. If each iteration needs its own data, create the object inside the iteration, or copy the fields you care about. ## What to say in an interview Name the mechanism, not the ritual: each iteration needs its own binding holding a snapshot, and a function call is simply the pre-ES6 way to manufacture one. Then note that `let` builds the same thing into the loop head, which is why the idiom is now history rather than practice.