On Jan 7, 2012, at 9:35 PM, Gavin Barraclough wrote: > On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: >> Remember, we are not proposing breaking semantic shifts of meaning for >> existing syntax. So the realistic worry is that you have code with >> arguments[i] aliasing a formal, and this is required for correct operation, >> and you then start using ES6 features (which imply ES5-strict), which breaks >> arguments aliasing. > > Hmmm, I was thinking this proposal implied much more of a breaking change > (e.g. removing the global object from scope),
Nope, as dherman's o.p. said: "giving up". But not the free variable analysis based on implicitly imported global object properties, for early errors on typos, of course. > but if the change in semantics largely comes down to enabling ES5-strict then > maybe this isn't so bad. If we are talking about implicitly enabling > ES5-strict for the whole program, I would think there may be a quite a few > more hazards to consider? (code that implicitly introduces variables onto the > global object, assumes this conversion to global object value in function > calls, uses callee/caller/arguments, etc). See Allen's state machine. It requires state transitions for the syntax whose meaning shifted from ES5 (non-strict, as Mark points out this is only part of ES5 so a misnamed label) to ES6. > Still, I'm warming up to the idea considerably if the implicit opt-in is > triggering no major breaking changes. The state machine won't trigger breaking runtime shifts but it will make early errors out of inconsistent combinations of ES5-nonstrict and ES6 features in a single program. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
