ES6 opt-in, reloaded
brendan at mozilla.org
Tue Jan 17 12:06:20 PST 2012
> Andreas Rossberg <mailto:rossberg at google.com>
> January 17, 2012 4:49 AM
> On 16 January 2012 19:35, Brendan Eich<brendan at mozilla.org> wrote:
>>> new ES6 features to classic
>>> mode, as has been proposed by several people, clearly works against
>> I object. 3 is misstated to assume "switching" means all-or-nothing. If ES6 has new features and they are worth using, developers will want to use them piecewise and conveniently. Assuming they will do so at the price of a leading "use version 6" or equivalent pragma is debatable. We shouldn't just assume this conclusion.
> OK. But that sounds like a clear departure from the "ES.next/Harmony
> is based on strict mode" axiom that everybody seemed to have agreed on
> long ago. Do we have consensus on abandoning that goal? (Thus my
> description as "backporting".)
It's not quite the departure you might think. E.g. destructuring formal
parameters piggy-backs on strict mode logic to forbid duplicates
anywhere in the parameter list. More below.
>>> and consequently, also against (5/6).
>> This does not follow. Users transitioning to use new features may be helped, not hindered, by we spec and implementation editors working harder. In particular allowing, e.g., destructuring in non-strict code may be boon to developers, whereas requiring them to maintain explicit opt-in pragmas before doing so simply to convenience spec editors and implementors may be a global loss.
> Adding new features to both modes is almost guaranteed to lead to new
> items to the list of non-strict vs. strict mode differences. That
> implies new refactoring risks. I don't see a way around that.
I do. We have strict mode changes, both early errors and runtime changes
in meaning. For the early errors, we piggy-back to make new syntax in
non-strict code trigger the same error, as with the destructuring
parameters example above. For runtime shifts in meaning, we can still
piggy-back if the change is "enclosed" by the new syntax.
What do I mean by enclosed? Consider destructuring parameters. Should
they trigger strict arguments object semantics, a runtime shift? No, the
destructuring pattern in one formal parameter does not enclose the whole
parameter list, or body uses of arguments. So what should arguments
semantics be? Non-strict.
Why isn't this a problem? Because destructuring parameters have no named
formal for the whole object passed as the actual and destructured by the
pattern. There's no need to alias, and we do not want deep-aliasing,
ever (we = users, implementors).
Is this split between enabling early strict-like errors for duplicates,
but not triggering strict arguments, a refactoring risk? I don't know. I
think we should look at it. It could be a risk, certainly -- but it may
>>> Similarly, opting in at
>>> smaller scope, as has also been discussed, is a blatant violation of
>>> (6) and (7), and works against (3), too.
>> Let's agree, based on your earlier arguments and also on Dave's point that lexical scope (free variable error analysis) won't work if opt-in is too local.
> OK, I'm really glad. :)
See, toldya es-discuss is not scary ;-).
>> Meanwhile, JS1 grew via ES1-5 and various implementations (SpiderMonkey and Rhino) without any such opt-in, *except* for two keywords we couldn't reserve (and some incompatible change attempts that failed, vs. goal 8 -- one example: I tried to make == and != strict in JS1.2 to get ES1 to switch, but that broke the web, wherefore === and !==).
> Doesn't that kind of make my point? Breaking changes, even small, need
attribute, remember that) failed. ES1 changed JS de-facto standards
without opt-in. Same for ES2 and 3. We supported versioning via
language= and later type= but it was hardly used outside of
Developers do not want version opt-in, certainly not as a requirement.
Have to stop here, out of time. Please feel free to reply to anything, I
hope I didn't miss something later in your message that invalidates what
I wrote in this message!
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 770 bytes
Desc: not available
More information about the es-discuss