A few arrow function specification issues

Brendan Eich brendan at mozilla.org
Sat Apr 21 12:00:58 PDT 2012


Allen Wirfs-Brock wrote:
> 1) Always strict? Should all arrow functions be considered strict functions?
>
> Pros
> P1. It's a new syntactic form, so it is it easy to make it be an implicit opt-in to strict mode.
> P2. We generally want to encourage use of strict mode.
> P3. If not, there would no way to to make an expression-bodied arrow function a strict function (other than by nesting it in strict code)
> P4. Always strict eliminates the need for some of the arrow special case alternatives discussed below
>
> Cons
> We shouldn't be trying to force use of strict mode.
> Programmers who don't know about strict mode may get confused by the application of strict mode  semantics to arrow functions
> It would create a refactoring hazard for non-strict code.

Pros outweigh Cons in my book, on their face. In particular the ones I 
took the liberty of labeling P3 and P4.

I thought per 1JS that modules opt into strict mode (P1 but stronger).

P4 is enough by itself unless there's a big Con. I don't see one big 
enough to matter.

> 2) Redeclaring eval in non-strict arrow functions
>
> Should strict mode eval declaration/assignment restrictions be be imposed upon non-strict arrow functions?
>
> I propose disallow binding eval or assigning to it all arrow functions

Yes, and implied strict mode handles this.

> 3) Declaring arguments as a formal parameter, or local binding in a non-strict arrow function
>
> The wiki proposal says arguments can't be used as an expression primary but doesn't say anything about declarations
>
> I propose binding or assigning or referencing arguments within a arrow function.

With missing "to disallow", agreed.

> 4) Should it be a dynamic error to try to use apply/call to set the this binding of an arrow function.
>
> Cons
> To much existing code speculatively binding the this value when invoking a function.
>
> I propose that call/apply simply ignore the this value when invoked on an arrow function.

Agreed. That's in the wiki proposal, as revised.

> 5)  Should arrow functions define the [[HasInstance]] internal method.
> In other words should should:
>      obj instanceof () =>  {}
> do?
> If it doesn't have [[HasInstance]] then instanceof would throw a type error.  Alternatively, it could have a [[HasInstance]] that always returns false.
> We have already decided that arrow functions don't have a [[Construct]] internal method nor a prototype property.

Yes, so it follows no [[HasInstance]]. This is an oversight in the proposal.

> I propose that arrow functions do not have a  [[HasInstance]] internal method.

Agreed.

> 6) Do arrow functions need to have per instance "caller" and "arguments" poison pill properties?
>
> I propose no, because they are a new feature. But we can include a NOTE warning against providing their non-standard legacy implementation.

NOTE sounds good, and we should not poison new ground.

> 7)All of the above questions also apply to functions defined using concise method syntax in object literals or classes.  Should the same answers apply to them?

Question 4 does not -- methods must have dynamic |this| and you can 
substitute another object via .apply/.call.

Otherwise I'd make them the same. I suspect there will be arguments to 
support new and instanceof. Use a function-valued property if you need 
to (my response).

/be


More information about the es-discuss mailing list