ES6 doesn't need opt-in

Andreas Rossberg rossberg at google.com
Mon Jan 9 02:49:15 PST 2012


On 5 January 2012 20:10, Brendan Eich <brendan at mozilla.com> wrote:
> On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote:
>> Sorry, I still think that a growing set of subtle implicit rules for
>> activating subtle semantic changes
>
> Not changes, new semantics for new syntax.

I was referring to strict vs classic mode. The way I understood the
discussion so far, certain syntax would implicitly opt into extended
mode, and thereby also into strict mode -- locally, and from classic.
That implies semantic changes for existing features.

[The discussion seems to have changed direction again with Allen's
"state machine" idea. That probably makes some of my comments
obsolete. Sorry for lagging behind.]

>> on a fine-grained level is far more
>> confusing (and error-prone!) than helpful. In all sorts of ways.
>
> Our experience was that adding new features to the default version where there was no backward incompatibility was not confusing. We've been doing this since 2006. Not to say all the particulars are right, or that we anticipated all the combinations of ES5-strict and Harmony, of course! But I think you protest too much without evidence.

Yes, but these didn't imply semantic changes to existing features,
like with implicit strict mode opt-in.

>> I'm also concerned about the 3 and a half language modes that might
>> result. With Dave's original proposal at least, the only opt-in was on
>> module level.
>
> Dave mentioned generators, IIRC. We were thinking of classes too (talked about it privately).
>
>
>> That precluded a number of highly undesirable
>> combinations, e.g. extended mode nested into a "with" statement.
>
> You can "use strict"; in a with statement's body block. But see below, I agree the opt in has to be "chunky", and is in the (not perfectly clear, complete, etc.) proposal for "ES6 doesn't need [version] opt-in".

We had been discussing opting in a function if it's using
destructuring on its parameters, for example. I would count that as a
case that is not "chunky" enough, because it can be local to "evil"
classic features and e.g. screw up lexical scoping. Likewise
generators. I really think we should avoid these cases.

[Now the idea seems to be that any ES6 feature would always opt-in the
whole program. A like that much better, but it is not what Dave
originally proposed, and what we had been discussing before, as far as
I can tell.]

/Andreas


More information about the es-discuss mailing list