ES6 doesn't need opt-in

Brendan Eich brendan at mozilla.com
Thu Jan 5 11:10:10 PST 2012


On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote:

>>> explicit opt-in)
>> 
>> No -- "use strict"; the string literal expression-statement is meaningless pre-ES5, ES5-strict in ES5, and redundant in Harmony code.
> 
> You said earlier that we best rely on the meta tag for the script
> toplevel, which isn't exactly a No. ;)

Trying to avoid scope creep. Also not dismissing RFC4329 ;version=6 parameter setting -- that works to hide new code from old browsers (I believe back to IE8 -- perhaps not the geriatric browsers).


>> Now what do you say?
> 
> Sorry, I still think that a growing set of subtle implicit rules for
> activating subtle semantic changes

Not changes, new semantics for new syntax. The fingers of fate may allow completion reform (Mark and I think so). The interactions are not that hard, and making a mode-wall doesn't avoid solving all of them -- you still may have runtime (heap-based) interactions between old and new modes.

We did JS1.7 this way, BTW. You had to opt in to get 'let' and 'yield', but that was for the compiler. We did not hold back other features, and there were no runtime (post-compile) version checks:

brendan-eichs-computer-3:src.old brendaneich$ grep VERSION_1_7 *.c
jsapi.c:    {JSVERSION_1_7,     "1.7"},
jsparse.c:                   || (JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c:                   ((JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c:                if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {
jsparse.c:            if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {

(jsapi.c is just a string <-> enumerator mapping table; jsparse.c shows the compiler checks.)


> 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.


> 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".


> Allen
> gave a couple of good examples we also ran into when trying to
> implement block scoping liberally in V8 -- in the end, we concluded
> that it doesn't make sense to allow opting into extended mode locally.

Yes, this is one place where during the ES4 period, we made 'let' at top level of program and function bodies equate to 'var', which is no good (arguments aliasing, for one). But lesson learned.

The idea is to opt in at least the enclosing function, if not the enclosing Program (non-terminal, so <script> element content) when unproblematic new syntax is parsed.

/be


More information about the es-discuss mailing list