JavaScript keyword "let" is not implemented to spec. Topic is solved

[NikolaNewton]

I have read some on this site about how "let let = value" and "var let = value" are not supported by PM, although I believe ES6 specifies that they are admissible except in strict mode.

That is not what this thread is about.

This thread is to report that the keyword "let" does not appear to correctly limit the scope of the closure when used within a control parenthesis, such as:

Code: Select all

for(let i=1; i<5; i++) 

as demonstrated here:
http://jsfiddle.net/rmXcF/4/

The red square should alert the number it contains.

[Moonchild]

I have read some on this site about how "let let = value" and "var let = value" are not supported by PM, although I believe ES6 specifies that they are admissible except in strict mode.

No, 'let' is a reserved keyword. The fact that some browsers allow it as an exception for (transitional) web compat doesn't make it any less of a reserved keyword in the ES6 standard.

That is not what this thread is about.

Then why mention it at all instead of focusing on the issue at hand?

The red square should alert the number it contains.

No, it shouldn't.
You're exiting the loop (which is the scope for which i is defined) having i at 6 (termination point). All you do in the loop is assigning the code to have the clicks return the current value of i -- you're not locking that value of i when you assign the code to the divs and as such it will return whatever the value is at the end of the loop.
When exiting the scope, the value gets frozen (at 6 at that point), which is what Pale Moon displays.

[NikolaNewton]

I was unsure about 'let' being disallowed in non-strict, but you are right ES6 did change that, thanks for clarifying.

But, it appears that in ES6 specification the specified behaviour is that in

Code: Select all

for(let i;;){}

i gets a new binding for every iteration of the loop.

This means that every closure captures a different i instance.

The proper behaviour is specified in
https://tc39.github.io/ecma262/#sec-for ... evaluation

A new lexical scope is created and is chained to its previous scope when let expression is used. Currently Chrome and Firefox have the correct implementation.

[Moonchild]

tc39 is being very cryptic but I still interpret our implementation as correct, unless I'm completely missing something.

"let i" isn't a constant expression, so even if a new binding is created it'll be mutable and i's value will propagate up the hierarchy.

Perhaps if you can get me the bugzilla bug where Firefox changed this, I can get more background and interpretation details.

[Mercury]

Mozilla's opinion on this seems quite clear, for whatever that's worth: https://developer.mozilla.org/en-US/doc ... _functions

It seems that PM treats "let i" same as "var i" in this case. Intuitively, it feels like they should be different.

ETA:
Also found this: https://hacks.mozilla.org/2015/07/es6-i ... and-const/

A comment by the author points to: https://bugzilla.mozilla.org/showdepend ... resolved=0

[NikolaNewton]

i will be mutable, but a separate instance will be created for each loopEnv.

Bugzilla didn't have anything official, only a bug like this one reported about a year ago, which they must have fixed without tracking, as the bug is still "unconfirmed": https://bugzilla.mozilla.org/show_bug.cgi?id=1281696

Here is related Chrome bug for further info: https://bugs.chromium.org/p/v8/issues/detail?id=4762

And maybe view this SO question: https://stackoverflow.com/questions/164 ... e-for-loop

[Moonchild]

... who the hell thought this up? And most importantly: why?

So, you create a mutable binding, meaning if you manipulate i it will affect the loop like a var, but at the same time a separate, non-propagating scope for each loop is required (making a for loop in effect a recursion) to treat i as a different variable for each iteration as-if it was passed as a constant into it...

That's confusing as hell -- is i mutable or non-mutable? "yes"

Also, the references pointed at are for the more common for..of and for..in situation, where this makes perfect sense, not C-style for(;;) loops where it creates confusion like above as to the state of the let-ed variable.

Thanks for the report though, I'll find a way to implement this nonsense -- it's in the spec after all. Issue #1432

[Moonchild]

Resolved in the next unstable. Feel free to verify when published (probably tomorrow).