A few arrow function specification issues

Brendan Eich brendan at mozilla.org
Mon Apr 23 11:01:37 PDT 2012


Allen Wirfs-Brock wrote:
> On Apr 23, 2012, at 8:19 AM, Brendan Eich wrote:
>
>> Andreas Rossberg wrote:
>>> To be honest, that suggestion confirms one of my fears about "1JS" --
>>> ending up with a more complicated language with ad-hoc rules about
>>> which mode applies in which context. Please let's try to resist the
>>> temptation. As much as I would like to encourage strict mode, I think
>>> we should keep it orthogonal to other constructs as much as possible.
>>> I can bear tying it to modules, but let's not go any further.
>> It's a good point (and I'm not one to "encourage strict mode" if there's no payoff for developers, but before agreeing, can you enumerate the cases that matter inside an arrow function body?
>>
>> Without arguments runtime semantic shifts, and with |this| lexical, there aren't many strict mode changes left IIRC, and they are pretty edgy edge cases.
>
> See Annex C.  Some strict mode highlights:
>
> Assignment to an unbound name throws instead of creating a property of the global object

Right. This one I want in new forms, and it's not ad-hoc if arrows imply 
strict mode. Limiting strict mode implication to modules is just as 
arbitrary and more user-hostile in my view. No one writing arrows wants 
to create globals implicitly, only to save themselves by typing a "use 
strict"; pseudo-pragma!

> With statements are disallowed

Ditto^2.

> direct eval can't instantiate new binding in the enclosing environment

Ditto^3.

> duplicate formal parameter names are disallowed

We disallow duplicates if destructuring formal parameters appear in any 
parameter list, in SpiderMonkey. We discussed doing this for any 
function with destructuring parameters as part of the 1JS thread early 
this year. I forget whether you spec'ed it already.

In that earlier discussion we did not agree that using a destructuring 
formal parameter in a 'function' declaration or expression opts the body 
of the function into strict mode. More the reverse -- one formal 
parameter novelty does not say "strict throughout". But it can certainly 
say "no duplicate formals" and no one minds. Duplicate formals are a 
botch from ES1, added only to match JScript, IIRC.


> (I suggest we add this restriction to arrow functions even if we say 
> they aren't inherently strict. ) 


Agreed.

1JS is about new syntax as opt-in for new semantics. Those new semantics can be strict in some or all respects. There is nothing more ad-hoc about this than requiring "use strict"; to opt-in, no one wants the botches you enumerate, and the implementations already have strict mode factored mostly to compile time and can impute strictness to arrows.

Really, the botches you enumerate *are* botches. They should not be perpetuated into new function or module syntax where the body is introduced by a keyword that can imply strictness. Neither users nor implementors want this. The philosphical purity of separating concerns is an abstraction that is hostile to the best interests of users from all testimony I've heard [*].

/be

[*] I've never heard from anyone defending any of the botches listed above except for 'with', and when I push, it turns out people are using 'with' to make PHP-style templates -- but the requirement for dynamic scope is a phantom and one can generate even more efficient templates using Function or eval (and libraries do).




More information about the es-discuss mailing list