ES6 doesn't need opt-in

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jan 4 09:35:00 PST 2012


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
      effect of multiple use of the same name - currently forbidden in strict mode but currently allowed in non-strict mode
      interaction between new formal parameter forms and non-strict mode arguments object
      how is declaration instantiation order for non-strict functions impacted by parameter default value expressions
      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.
 
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.  

Allen
   



More information about the es-discuss mailing list