A few arrow function specification issues

Angus Croll anguscroll at gmail.com
Sat Apr 21 13:02:40 PDT 2012


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

What is the pro of ignoring explicit |this| binding instructions in
call/apply on arrow functions?
What is the con of continuing to allow legacy code to speculatively bind
the |this| value when invoking any function?
Why is it so important that fat arrows do a hard |this| binding?



On Fri, Apr 20, 2012 at 4:22 PM, 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.
>
> 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?
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120421/3f0ee011/attachment.html>


More information about the es-discuss mailing list