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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss