<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 4, 2012, at 9:35 AM, Allen Wirfs-Brock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote:<br><br><blockquote type="cite">...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><br>I don't think we every contemplated forbidding implementations from extending non-strict modes with versions of new features ES6 features.<br><br>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:<br>      using 'arguments'  (or 'eval') in a formal parameter destructuring pattern or as a rest parameter - currently forbidden by strict mode<br></div></blockquote><div><br></div>Destructuring opts into strict mode or rather its successor, ES.next. Harmony rolls on this way.</div><div><br></div><div><br><blockquote type="cite"><div>      effect of multiple use of the same name - currently forbidden in strict mode but currently allowed in non-strict mode<br></div></blockquote><div><br></div>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.</div><div><br></div><div><div><font class="Apple-style-span" face="Courier">js> function f({a,b},a){}</font></div><div><font class="Apple-style-span" face="Courier">typein:1: SyntaxError: duplicate argument is mixed with destructuring pattern:</font></div><div><font class="Apple-style-span" face="Courier">typein:1: function f({a,b},a){}</font></div><div><font class="Apple-style-span" face="Courier">typein:1: ............^</font></div><div><font class="Apple-style-span" face="Courier">js> function f(b,{a,b}){} </font></div><div><font class="Apple-style-span" face="Courier">typein:2: SyntaxError: duplicate argument is mixed with destructuring pattern:</font></div><div><font class="Apple-style-span" face="Courier">typein:2: function f(b,{a,b}){}</font></div><div><font class="Apple-style-span" face="Courier">typein:2: .................^</font></div><div><font class="Apple-style-span" face="Courier">js> function f({a,a},c){} </font></div><div><font class="Apple-style-span" face="Courier">typein:3: SyntaxError: duplicate argument is mixed with destructuring pattern:</font></div><div><font class="Apple-style-span" face="Courier">typein:3: function f({a,a},c){}</font></div><div><font class="Apple-style-span" face="Courier">typein:3: ...............^</font></div><div><br></div><div><br></div><blockquote type="cite"><div>      interaction between new formal parameter forms and non-strict mode arguments object<br></div></blockquote><div><br></div>See above. Function is implicitly strict.</div><div><br></div><div><br><blockquote type="cite"><div>      how is declaration instantiation order for non-strict functions impacted by parameter default value expressions<br></div></blockquote><div><br></div>See above, again.</div><div><br></div><div><br><blockquote type="cite"><div>      can the temporal dead-zone rules related to parameter default value expression evaluation in strict mode also apply to non-strict functions<br></div></blockquote><div><br></div>Ditto.</div><div><br></div><div><br><blockquote type="cite"><div>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.<br></div></blockquote><div><br></div>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!</div><div><br></div><div><br><blockquote type="cite"><div>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.  <br></div></blockquote></div><br><div>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!</div><div><br></div><div>/be</div></body></html>