ES6 doesn't need opt-in

Brendan Eich brendan at
Fri Jan 6 12:34:40 PST 2012

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.



More information about the es-discuss mailing list