On Jan 6, 2012, at 12:25 PM, Allen Wirfs-Brock wrote:

> On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote:
> 
>> Or (no quotes)
>> 
>> use strict;
>> 
>> I think we want this pragma supported, not only the string-literal 
>> expression-statement "directive".
> 
> If we end up with all of ES6 being a super set of ES5 strict, then I don't 
> see a lot value in saying:  use strict;

The value is that the string literal is non-breaking in pre-ES5 
implementations, which has been a source of real bugs (concatenation, too-early 
adoption).

Explicit opt in via

  use strict;

seems better to me than anything with a version number in it. More below.


> I would think that:
>   use ES6;  //or use version 6; etc
> would better express the user intent.
> 
> BTW, I would interpret this as meaning "at least ES6" and still do feature 
> driven version detection of future versions using an expanded state machine.

While the ECMA editions will be numbered (unpredictably!), and RFC4329 points 
toward post-hoc standardization of the ;version= MIME type parameter, I do not 
think we should embed version numbers in pragmas.

We could, certainly. That was the plan of record until recently. It matches the 
;version= progression we're likely to want anyway, to hide new code from being 
loaded by old browsers with inevitable syntax errors whose reporitng slows the 
futile loads even further.

But I'd rather leave ;version= to the MIME type parameter, which is just a 
post-hoc reflection of ECMA's edition numbering. This reduces the tendency to 
think of versions, modes, and the like. It's a human factors thing. Versions 
suck, Hixie and Anne and others were right to push back on them, even if they 
didn't solve the forward compatibility problem (no one has) or are in denial 
about HTML5 (with 5) :-P.


> Other ES5 opt-ins at the top level include:
> 
> var arguments;
> 
> function ES5(yes,yes){};
> 
> These probably won't cause any deoptimization.
> 
> However, I agree that it would be rare for someone to actually need to do 
> this.  The intent was more to emphasize that the way you force a particular 
> spec-level interpretation is to code something that is unique to that 
> spec-level.

Sure.

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

Reply via email to