ES6 doesn't need opt-in

Brendan Eich brendan at
Sat Jan 7 23:11:41 PST 2012

On Jan 7, 2012, at 9:35 PM, Gavin Barraclough wrote:

> On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote:
>> Remember, we are not proposing breaking semantic shifts of meaning for existing syntax. So the realistic worry is that you have code with arguments[i] aliasing a formal, and this is required for correct operation, and you then start using ES6 features (which imply ES5-strict), which breaks arguments aliasing.
> Hmmm, I was thinking this proposal implied much more of a breaking change (e.g. removing the global object from scope),

Nope, as dherman's o.p. said: "giving up". But not the free variable analysis based on implicitly imported global object properties, for early errors on typos, of course.

> but if the change in semantics largely comes down to enabling ES5-strict then maybe this isn't so bad.  If we are talking about implicitly enabling ES5-strict for the whole program, I would think there may be a quite a few more hazards to consider? (code that implicitly introduces variables onto the global object, assumes this conversion to global object value in function calls, uses callee/caller/arguments, etc).

See Allen's state machine. It requires state transitions for the syntax whose meaning shifted from ES5 (non-strict, as Mark points out this is only part of ES5 so a misnamed label) to ES6.

> Still, I'm warming up to the idea considerably if the implicit opt-in is triggering no major breaking changes.

The state machine won't trigger breaking runtime shifts but it will make early errors out of inconsistent combinations of ES5-nonstrict and ES6 features in a single program.


More information about the es-discuss mailing list