Initializer expression on for-in syntax subject
Sad panda. At least we can disable it in strict mode, right?
And who knows, maybe some day, some day...
Dave, dreaming of ES24
On Fri, Mar 14, 2014 at 12:29 PM, David Herman <dherman at mozilla.com> wrote:
Sad panda. At least we can disable it in strict mode, right?
yes!
And who knows, maybe some day, some day...
Dave, dreaming of ES24
I'll hazard a public prediction for the record:
Since ES6 does implicit strict opt-in for both classes and modules, by the time of wide ES7 deployment, sloppy mode will no longer matter much for new code. Or ES8 at the latest.
It's just a prediction, so no need to argue until we're in the predicted timeframe.
I'd be curious to know what the actual code is, and to get an idea why they are using it that way.
for (var i = 0 in debug.audio)
I say we should evangelize this site. Cc'ing some awesome Mozilla site evangelists.
Brendan Eich wrote:
for (var i = 0 in debug.audio)
BTW, ur-JS in Netscape would not parse this. The optional initializer fell out of grammar over-reuse in ES1, possibly also works-in-JScript lobbying (my memory fades but that is where it came from).
I suggested to Oliver that we accept "Identifier = Expression in Expression” as valid syntax, but drop "= Expression” from the parse tree after the fact. That way, we can still almost completely remove the construct from the language without harming web compatibility.
I don’t see much value in making this decision based on strict mode. So far, we’ve got nothing but trouble from policies like that.
Geoffrey Garen wrote:
I suggested to Oliver that we accept "Identifier = Expression in Expression” as valid syntax, but drop "= Expression” from the parse tree after the fact.
Note that the issue here is only legacy that uses 'var' before Identifier. So you can't be sure of no compat break, since
for (var x = 'haha' in {});
with no enumerable properties on Object.prototype will iterate zero times, and the hoisted var x will be initialized to 'haha' and available after the loop.
That way, we can still almost completely remove the construct from the language without harming web compatibility.
I wish. But let's just evangelize the site, and any others that use this botch from the ancient world (JScript => ES1).
I don’t see much value in making this decision based on strict mode. So far, we’ve got nothing but trouble from policies like that.
I agree we shouldn't fuss with strict mode, it doesn't pay. We should impulse-shoot the bad old form, right between the eyes, in ES6.
On Fri, Mar 14, 2014 at 3:31 PM, Brendan Eich <brendan at mozilla.org> wrote:
Geoffrey Garen wrote:
I don’t see much value in making this decision based on strict mode. So far, we’ve got nothing but trouble from policies like that.
Your "nothing but" claim is so silly it doesn't need a serious response. There are a zillion counter-examples starting with lexical scoping.
But leaving aside the "nothing but" silliness, what trouble do you have in mind?
I agree we shouldn't fuss with strict mode, it doesn't pay. We should impulse-shoot the bad old form, right between the eyes, in ES6.
Hey, if we can kill the bad feature completely, great. The strict mode suggestion is only relevant if we can't kill it is sloppy mode.
Peter van der Zee wrote:
Which browsers currently don't accept this construct? I wasn't even aware that JSC didn't support it at some point.
Did anyone say JSC lacked support? I think KJS followed ES3, and this was in the ES1 grammar, so I doubt it was never supported.
Minifiers might rely on this construct. And perhaps some js1k entries, if that matters anything.
Extremely doubtful. It doesn't save anything. A minifier cannot count on the loop iterating 0 times.
Why is there a desire for banishment anyways? Only lack of consistency compared to not using the var keyword,
This is only about the 'var' case. The initialiser in 'for (var x = y in z)' is due only to reuse of the wrong grammar nonterminal in ES1, based on JScript de-facto non-standard behavior. It is a wart and a pain to implement. We don't expect it to be hard to remove, unlike other warts, but we'll find out.
or was there a bigger problem with this? The thread comes out of the blue to me so I probably missed a prior discussion :)
ES6 revised the old grammar dating from ES1, breaking for(var x = y in z). That was intentional and discussed in past meetings and threads.
If we can get uglify and closure compiler to reject it it will go a long way toward making sure it doesn't crop up in the wild.
Brendan Eich wrote:
Did anyone say JSC lacked support? I think KJS followed ES3, and this was in the ES1 grammar, so I doubt it was never supported.
Of course I was excluding the recent removal per draft ES6 that Oliver mentions in the root of this thread, "JSC has been trying to kill off the initialiser expression in the for(in) statement" -- sorry for confusion. Just to be clear, this is recent and per ES6, intentional.
Hoping my site evang pals can get somewhere with battlefield.com.
I’ve landed the change to JSC to silently ignore the assignment in the non-strict var ident = case, everything else is still an error so deconstruction and of enumeration will trigger a syntax error.
On 3/14/14, 15:53, Brendan Eich wrote:
I say we should evangelize this site.
I've filed bugzilla.mozilla.org/show_bug.cgi?id=987889 to track this.
For those not following the bug, a fix for this has been committed to the battlefield.com codebase.
[13:16] <mekwall> miketaylr: fix committed, just need to see if we can hot patch it. we just deployed a new release today and the next one is in two weeks
Huzzah!
JSC has been trying to kill off the initialiser expression in the for(in) statement, but we've encountered a bunch of reasonably significant content that breaks with it disallowed (a particularly prominent one currently is battlelog.battlefield.com/bf4), so we will be bringing back support for
for (var Identifier = Expression in Expression)