ES6 doesn't need opt-in

Brendan Eich brendan at
Wed Jan 4 13:07:32 PST 2012

On Jan 4, 2012, at 9:35 AM, Allen Wirfs-Brock wrote:

> On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote:
>> ...
>> Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code.
> I don't think we every contemplated forbidding implementations from extending non-strict modes with versions of new features ES6 features.
> However, your assumptions that destructuring has has no mode dependencies is wrong and a good example of why it is not so trivial to "include" it in non-strict code. Here are some of the dependencies  I've already run into WRT formal parameter destructuring:
>      using 'arguments'  (or 'eval') in a formal parameter destructuring pattern or as a rest parameter - currently forbidden by strict mode

Destructuring opts into strict mode or rather its successor, Harmony rolls on this way.

>      effect of multiple use of the same name - currently forbidden in strict mode but currently allowed in non-strict mode

Not allowed by JS1.[78]* in SpiderMonkey or Rhino -- we prefigured ES5-strict on this, for sanity. When you use destructuring parameters in Firefox, you cannot have duplicate parameter names *anywhere* in the parameter list.

js> function f({a,b},a){}
typein:1: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:1: function f({a,b},a){}
typein:1: ............^
js> function f(b,{a,b}){} 
typein:2: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:2: function f(b,{a,b}){}
typein:2: .................^
js> function f({a,a},c){} 
typein:3: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:3: function f({a,a},c){}
typein:3: ...............^

>      interaction between new formal parameter forms and non-strict mode arguments object

See above. Function is implicitly strict.

>      how is declaration instantiation order for non-strict functions impacted by parameter default value expressions

See above, again.

>      can the temporal dead-zone rules related to parameter default value expression evaluation in strict mode also apply to non-strict functions


> These tend to be subtle issues and the "right" answer is not always obvious.  If different implementors decided to add the new formal parameter affordances to non-strict mode, without any guidance, they would likely come up with differing solutions to some of these issues and hence create imcompatabilities.

We need a normative spec, of course! But we do not need to support new features in pre-strict-mode, indeed pre-ES6, combinations. New syntax is the opt-in!

> BTW, The simplest way to work around these issues, that I've found,  would be to say that any function that uses any new formal parameter syntax is implicitly a strict mode function.  

Sorry, I should have read this far. I guess the proposal was unclear enough that people went down a bad path (at least you, probably Mark and Andreas). Sorry about that -- the intention (at least my view of it when reviewing Dave's draft proposal) was that new syntax opts in, and at a function granularity at least!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list