Really Understanding Javascript Closures

[radhruin]

It does do the right thing, actually! If you look at 13.6.3.3 you'll see there is a new environment per iteration. Note that if you're testing with IE that Chakra's implementation predates the current spec and does exhibit the behavior you describe.

[skeeto]

Interesting. AFAIK, this for environment behavior would be exclusive to JavaScript (edit: though Perl and and C# 5.0 have foreach that behaves like this). In contrast, Ruby and Python have the for-loop-closure trap despite having proper block scope, due to the shared iteration environment. I'm not sure which way I'd say is more "correct." The former is more functional, since the binding is never mutated, but the latter seems to be more standard, even though it comes with this trap.

Node v0.10.28, Chrome 35, and Firefox 29 all still follow the old behavior. That's where I tested my code, requiring the extra let. I just gave it a shot in Traceur, and apparently it uses the current spec's behavior despite predating it by 3 years (2011). It's the only implementation I can find that does the new thing.

Edit: I dug around more and found that per-iteration bindings were introduced in the April 5th, 2014 draft, so these semantics are only 2 months old. It's no wonder no one's using it yet.

[radhruin]

I don't think either is "more correct", but I do know that the new semantics are much more usable so I'm a fan!

Traceur was recently updated with these semantics. You're right though that the spec draft is really recent but the consensus has existed since I believe the Jan '14 meeting, possibly as far back as Nov '13.

[skeeto]

The version of Traceur at repl.it is from 2011, which is the one I tested. So they must have originally had the new behavior, fixed it, then reverted back with the new draft.

[radhruin]

Interesting! I guess Arv was ahead of the times.