excluding features from sloppy mode
brendan at mozilla.com
Sat Dec 29 13:26:47 PST 2012
Mark S. Miller wrote:
> On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich<brendan at mozilla.com> wrote:
>> Who ever proposed that? It seems a misunderstanding. No one is saying that,
>> e.g., destructuring formal parameters, or a rest parameter, should flip the
>> containing function into strict mode. Banning duplicate formals in no wise
>> does that.
> This is an example of the micro-modes issue. If optional, rest, and/or
> destructuring needs to enforce no duplicates, then we have two
> 1) Make these features available only in strict code, which doesn't
> require any new special case -- since strict already bans duplicate
> parameter names.
Agree so far.
> 2) Make a micro-mode, adding yet additional mode switching in order to
> supposedly avoid the complexity of dealing with one mode switch.
No, you are using micro-mode as an epithet without actually defining it
in a meaningfully different way from "new semantics for new syntax".
Are arrow functions, syntax and definite semantics, a "micro-mode"? If
not, why not? I suspect you are using a mental desugaring spec but
there's no such spec. Allen has to deal with whether arrows have
[[Construct]] (we decided no, because |this| is bound to outer |this|).
Is that a "micro-mode"? I say no.
> By our previous criteria, #1 is obviously simpler than #2.
I dispute that. The complexity to count is user-facing, not
spec-internal or mental-desugaring or other invisible complexity. Users
need to know about arrows when writing them. When calling, not so much
(one cannot assume all functions are constructors, even in ES1 [builtins]).
Let's try to get to an apples-to-apples user-facing complexity metric,
and leave the stuff under the spec hood out.
More information about the es-discuss