A few arrow function specification issues

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Apr 20 16:22:27 PDT 2012


Here are a few design alternates that have come up as I work the specification draft for arrow functions

1) Always strict? Should all arrow functions be considered strict functions?

Pros
It's a new syntactic form, so it is it easy to make it be an implicit opt-in to strict mode.
We generally want to encourage use of strict mode.
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)
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.

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

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. 

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.

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.

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

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.

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?


More information about the es-discuss mailing list