ES6 doesn't need opt-in

Brendan Eich brendan at
Fri Jan 6 13:07:51 PST 2012

On Jan 6, 2012, at 1:03 PM, Axel Rauschmayer wrote:

>>> Then I would only expect two labels: ES6 and non-strict
>> You're counting different beans from Mark's "modes" and from Allen's states.
>> The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again.
> Ah, got it! You want ECMA-262 version 6 to allow an à la carte approach: implementors can choose between non-strict ES5, strict ES5, ES6, etc.

No! ES6 will be a normative all or none spec, ignoring informative annexes and Annex B (revised to be normative-optional, meaning if you implement these APIs you must follow this annex, but you are not required to implement them).

The issue is *how* the spec and implementations decide what is supported, and when to raise an error on new syntax mixed (after) old non-strict code (e.g., 'with').

>> I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works.
> I was thinking about how to specify only (exclusively) an ES6 environment. You pretend to live in a “perfect ES6 world” and then only have two labels. There are two ways out of this world:
> - Non-ES6 environments for implementors: refer to ECMA-262 version 5.1.
> - Non-ES6 environments for developers: simulate ES6 (via static compilation, dynamic compilation, etc.).

That's fair, and some developers will just assume ES6 and require latest l33t browsers. There are many possible bean-counting approaches depending on your business, hobby, mood, etc.

For the spec we need an algorithm for syntax-as-opt-in. That's what the state machine is about.


More information about the es-discuss mailing list