ES6 doesn't need opt-in

Mark S. Miller erights at
Fri Jan 6 19:29:58 PST 2012

Axel, thanks. This is the critical point, so no apologies needed for
Allen, what I mean is exactly what Axel says here.

Look at it another way. Right now we have two normative modes: ES5 strict
and ES5 non-strict. State machine aside, ES6 introduces a new single mode
normative spec. If the state machine may delegate to any of these three
normative specs we have three modes. If the state machine may only delegate
to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as
of conformance with state machine + ES6 spec, then we have two modes.

To get this effect, we need only classify ES5's "use strict"; directive as
ES6-only. If any objection to doing so has been stated, I missed it. Is
there a reason not to do so? It's a one line change that leaves the rest of
your proposal unperturbed and solves this problem.

On Fri, Jan 6, 2012 at 12:09 PM, Axel Rauschmayer <axel at> wrote:

> > Rather, we should minimize the state machine and how we talk about it.
> We could generalize it using Curr, Next, Curr&Next, and Curr-Next labels.
> I’m awfully sorry for belaboring this point. But the labels and the quote
> below don’t go together.
> Quoting Brendan:
> >> - ES6 is a superset of ES5.strict.
> >
> > That's always been promised.
> Then I would only expect two labels: ES6 and non-strict
> ES6-only => (a subset of) ES6
> ES5-only => only possible for non-strict constructs => non-strict
> ES5&ES6 => (a subset of) ES6
> ES5~EAS6 => not possible  (“The construct has identical syntax and static
> semantics in both ES5 and ES6, but differing semantics.”)
> --
> Dr. Axel Rauschmayer
> axel at
> home:
> twitter:
> blog:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list