ES6 doesn't need opt-in
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:
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.
More information about the es-discuss