January 19 meeting notes

Brendan Eich brendan at mozilla.org
Thu Jan 19 20:02:57 PST 2012

> Waldemar Horwat <mailto:waldemar at google.com>
> January 19, 2012 4:40 PM
> Discussion about scope of for-bindings.
> for (var x = ...;;) {...}  will, of course, retain ES1 semantics.
> for (let x = ...;;) {...}
> Allen: This will behave as in C++: x is bound once in a new scope 
> immediately surrounding just the for statement.
> DaveH: Strangely enough, this creates a new x binding in Dart at each 
> iteration.
> There's an alternative semantics that creates an iteration-local 
> second x inside the loop and copies it back and forth.  Debate about 
> whether to go to such complexity.  Many of us are on the fence.
> Waldemar: What happens in the forwarding semantics if you capture the 
> x inside a lambda in any of the three expressions in the head?
> If this happens in the initializer:
> DaveH's option: The lambda would capture an outer x.
> Alternative: The lambda captures a hidden second x.
> Waldemar's option: The lambda would capture the x from the first 
> iteration.  The let variable x is bound once through each iteration, 
> just before the test, if
>   for (let x = expr1; expr2;) {...}
> were:
>   while (true) {
>     let x = first_iteration ? expr1 : value_of_x_from_previous_iteration;
>     if (!expr2)
>       break;
>     ...
>   }
> MarkM:  Just discovered that his desugaring has the same semantics as 
> Waldemar's option.
> for (const x = ...;;) {...}  behaves analogously to let, whatever we 
> decide let will do.
> Those opposed earlier to new-binding-per-iteration hop back onto the 
> fence.  Waldemar, Brendan, and DaveH hop off the fence to now support 
> it, as it will cure an annoying gotcha in practice.  Looks like we 
> have support for it now.

Yes kids, this means we are going with MarkM's lambda desugaring from:


So any closures formed in the body of such a for(let...;...;...) loop 
will capture the binding created afresh for that iteration. This avoids 
the nasty need for CoffeeScript "do" or the expanded JS equivalent of an 
IIFE surrounding the closure to create per-iteration storage for a copy 
of the loop control variable.

Contrary to Jon Zeppieri's good argument at



     let x = 0;
     for (; x<  n; x++) ...

should have different behavior than

for (let x = 0; x<  n; x++) ...

  those of us left from the TC39 meeting (missing a few reps, short of 
quorum) favored the greater-good argument ofprogrammer who follow'let is 
the new var' and who form closures in loops benefiting from the fresh 
let binding being captured, instead of one binding per loop where the 
likely value of the binding is the terminating loop control.

Yay (I'm pretty sure).


More information about the es-discuss mailing list