Output Quiz #2 — Closures & the Loop Problem

Output:

3
3
3

Why: All three setTimeout callbacks close over the same i variable — there is only one i because var is function-scoped. By the time the callbacks run (after the loop finishes), i is 3. Each callback logs the current value of i, which is 3 for all of them.

Output:

0
1
2

Why: let in a for loop creates a new binding for each iteration. Each callback closes over its own copy of i — not a shared variable. When the callbacks run, each one reads its own frozen value (0, 1, 2).

Output:

0
1
2

Why: The IIFE is called immediately on each iteration, passing the current value of i as j. Each callback closes over its own j parameter (a new variable in each IIFE invocation), not the shared i. This was the standard pre-let workaround.

Output:

2
3

Why: Both increment and getCount close over the same count variable in the outer makeCounter scope — they share live access to it, not a snapshot. snap is just another reference to the same getCount function. Calling snap() after a third increment() still reads the current value of count, which is now 3.

Output:

updated

Why: read closes over the variable value itself, not the string "original". When value is reassigned to "updated" before read() is called, the closure sees the new value. Closures capture variables, not values — this is the root cause of the classic loop problem too.

Output:

8
13
false

Why: Each call to makeAdder creates a brand new execution context with its own x binding. add5 closes over x = 5; add10 closes over x = 10. They are entirely independent function objects — add5 === add10 is false.

Output:

42
84

Why: Both reveal and double are closures over the same secret variable. double mutates it; reveal reads it. Since they share the same lexical scope, changes made by double are immediately visible to reveal. secret is private — it can't be accessed directly from outside createObj.

Output:

3
3
3

Why: Same root cause as Q1 — all three arrow functions close over the single var i. The loop runs to completion (i becomes 3) before any function is called. All three calls return 3. Change var to let and you get 0, 1, 2.

Output:

11
12
11

Why: Each call to outer() creates an independent closure environment with its own x. fn1 and fn2 do not share x. fn1() called twice increments its own x from 10 to 11, then 12. fn2() starts its own x fresh at 10, increments to 11.

Output:

1
2
3

Why: The IIFE runs once, creating a count variable and returning the inner function. result holds that inner function. Each call to result() increments and returns count. Because the IIFE has already run, there's no way to reset count from outside — it's private state managed by the closure. This is the module pattern.