On Oct 13, 2010, at 5:35 PM, Brendan Eich wrote:

> On Oct 13, 2010, at 4:31 PM, Mark S. Miller wrote:
>> * ES5/strict implementations as deployed in non-beta releases should obey 
>> <http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors>.
>>  If they don't, then either a separate opt-in will be necessary or we will 
>> have to retreat from some of the accepted harmony proposals. For example, if 
>> browsers deploy a harmony-incompatible semantics for "let", "const", and 
>> nested named functions, and if ES5/strict code comes to depend on those 
>> non-standard extensions, then without an additional opt-in it becomes 
>> impossible to deploy harmony without breaking that code.
> 
> The point about let, const, and function in block is good but I'll take it up 
> in a separate message.

Here are my thoughts. Reactions, advice, alternatives I've missed all welcome:

1. No one can claim to have future-proof ("Harmony-compatible") let until we 
really draft it better. Same for const. At the last TC39 meeting I proposed we 
drop hoisting to block-top and go with Scheme let* or C++ declaration-scope 
semantics, and everyone agreed (with great relief). But we haven't 
draft-spec'ed or prototyped this at all. It needs to be more solid.

2. Everyone wants to promote "use strict" but with Firefox 4 betas supporting 
most but not all of it, and the (still being debugged) complete patch just 
landed on WebKit nightlies, it is premature to try to get developers slapping 
the directive on new code. This already bit back due to concatenation with old 
code, and with lack of validation. We do not want to risk creating pressure for 
quirks mode strict mode!

3. Firefox's let and const support could create quirks-mode pressure on other 
browsers. This happens, and not just on non-IE, lesser-market-share browsers 
(Mozilla gets pressure from WebKit all the time, mostly for the good!). So 
there' s a risk here. But:

4. Forbidding our let, const, and function-substatement extensions under "use 
strict" -- especially forbidding let and const -- will harm uptake of validated 
strict mode usage in Mozilla-specific JS (add-ons, our front end JS, middle-end 
JS components, etc.). Maybe that's ok, we can try to use our long-standing 
"strict option" (which gives warnings by default, and overlaps ES5 strict mode 
but is not the same as it).  This harm has to count for something, even if hard 
to quantify -- the risk in 3 is hard to measure too (probably small).

5. You didn't mention 'yield', which ES5 strict makes a future reserved word, 
but which we implement in a possibly Harmonious way. We could play it safe in 
terms of future proofing, again at the risk of dampening "use strict" uptake in 
Mozilla-specific JS. Or we could gamble that we are already future-proof.

My tentative conclusion is that we should make ES5 strict forbid let, const, 
and function in block (or any substatement) in Firefox 4. I would hope (haven't 
tested it) that JSC will do likewise with function in block. Mozilla JS hackers 
can lean on the "strict option" and its warnings, which would deviate further 
from ES5 strict by not banning let, const, and function in block.

On yield, I'd like to let it ride. It's a good bet IMHO. But who knows?


> http://wiki.ecmascript.org/doku.php?id=proposals:versioning

(Collin Jackson added to this; I wrote the original version.)

/be

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to