A few arrow function specification issues

Andreas Rossberg rossberg at google.com
Mon Apr 23 02:15:07 PDT 2012

On 21 April 2012 01:22, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 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.

One more: It makes the rules for what mode applies where more
complicated and less obvious.

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.

> 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

Same here. If it's sloppy mode, let the sloppy mode rules apply as usual.

> 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.

I suppose the most natural semantics would be that, like 'this', '
arguments' is bound lexically from a surrounding function, if present.
But that's perhaps too confusing, so I'd be fine with ruling out its
use completely.

> 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.

Yes, that is consistent with what happens today when you call/apply a
function after 'bind'.

> 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.

Agreed. It would be weird to support HasInstance in the absence of the other.

> 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.

For simplicity and uniformity, I'd keep the same semantics as for
ordinary functions. Don't special-case if there is no strong reason to
do so.

> 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?

I'd prefer if concise method syntax stayed simple syntactic sugar for
functions. Methods obviously need dynamic this. If you combine that
with changes like the above, then you have implicitly introduced a
third kind of function that cannot be described as (simple) syntactic
sugar for any of the other two. That would be unfortunate, IMO.


More information about the es-discuss mailing list