ES6 doesn't need opt-in

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jan 6 12:25:57 PST 2012


On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote:

> (This grew out of a conversation Allen and I had yesterday -- great to see it developed.)
> 
> One thing to make clear:
> 
>> ES5~EAS6:  The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.  For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object.
> 
> This is something we propose to do with completion reform, and also until this year for typeof null.
> 
> It's clear we can't get away with changing typeof null == "null". Even with full opt-in, it's a runtime migration hazard (one of the five fingers of fate). I withdraw it -- I'm the one who proposed it in lieu of an Object.isObject predicate -- but I do not think we should add Object.isObject either.
> 
> Rather, we need to rethink reflection on types in light of not only null vs. object, but value types/proxies. I'd rather not rush that. In the mean time, and for lo these 16 years (heading toward 17!), developers have coped and can continue to do so with typeof x == "object" && x === null or simpler (!x, x == null, other context-specialized combinations).
> 
> In general, the latest "new syntax is its own opt-in" thinking, with Allen's state machine approach, means our five fingers of fate have to be small enough that we can get away with them. At least Mark and I believe completion reform (making the completion value depend on a statically decidable expression-statement) is the only such finger we can get away with folding right now.
> 
> 
>> If you want to explicitly force ES6 processing put a:
>>  let ES6;
> 
> Or (no quotes)
> 
>  use strict;
> 
> I think we want this pragma supported, not only the string-literal expression-statement "directive".

If we end up with all of ES6 being a super set of ES5 strict, then I don't see a lot value in saying:  use strict;

I would think that:
   use ES6;  //or use version 6; etc
would better express the user intent.

BTW, I would interpret this as meaning "at least ES6" and still do feature driven version detection of future versions using an expanded state machine.  

> 
> 
>> at the top of the source file. 
>> 
>> If you want to explicitly force ES5 processing put a:
>>  with (5);
>> at the top of the source file
> 
> That will potentially deoptimize the top level for some engines, but maybe it doesn't matter. I don't expect it to catch on ;-).

Other ES5 opt-ins at the top level include:

var arguments;

function ES5(yes,yes){};

These probably won't cause any deoptimization.

However, I agree that it would be rare for someone to actually need to do this.  The intent was more to emphasize that the way you force a particular spec-level interpretation is to code something that is unique to that spec-level.


Allen




More information about the es-discuss mailing list