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, ES.next. 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
Ditto.
> 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!
/be_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
