On Feb 4, 2012, at 8:01 AM, Jason Orendorff wrote: > On Sat, Feb 4, 2012 at 8:02 AM, Jason Orendorff > <jason.orendo...@gmail.com> wrote: >> On Fri, Feb 3, 2012 at 7:26 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> >> wrote: >>> Under the scoping rules TC39 has agreed to, the initializer of a let/const >>> is always shadowed by the binding it is initializing[...] >> >> That rule doesn't make sense in this context. There should be either >> one V for the whole loop, or one V per iteration. Having both seems >> perverse. > > I just realized—the loop variables have to be visible in the > init-expressions if we want to support this: > > for (let a = getThings(), i = 0, n = a.length; i < n; i++) > > This is maybe not the best way to write "for (thing of getThings())", > but people will write it, and so it probably ought to work. I think > this is more important than escaping closures. This means that if such > loops will have per-iteration bindings, they should have an additional > set of bindings just for initialization-time—which seems ugly. Maybe > it's not worth it.
That's what the initial let V = INIT I said you needed in your de-sugaring was intended to address > > There is also this: > > for (let i = 0; i < n; ) { > setTimeout(...closure using i...); > if (shouldAdvance()) > i++; > } > > This will not work no matter what semantics we choose. However, > per-iteration bindings risk encouraging people to hit this problem. The } finally { %tmp = V } in your desugaring takes care of making sure that the the V value of the previous iteration is available to the TEST expression > > These two issues give me pause. > > -j > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss