arrow function syntax simplified

Dmitry Soshnikov dmitry.soshnikov at
Mon Apr 2 13:19:09 PDT 2012

On Mon, Apr 2, 2012 at 12:47 PM, Brendan Eich <brendan at> wrote:

> Douglas Crockford wrote:
>> On 4/2/2012 8:24 AM, Brendan Eich wrote:
>>> Jorge wrote:
>>>> I saw it
>>>> here:<**blog/2012/03/30/what-is-the-**
>>>> meaning-of-this<>>
>>> Right -- I think Doug was remembering the "Harmony of My Dreams"
>>> sharp-functions
>>> (**01/harmony-of-my-dreams/#**
>>> sharp_functions<>
>>> ),
>>> but arrows express mutable function objects per
>>> function_syntax<>
>>> which is the current source of truthiness.
>>> I left a comment about this on the YUI blog, saw it post yesterday, but
>>> it's gone now. Cc'ing Doug.
>> It seems I misunderstood what we were agreeing to. I think the (this...)
>> form is critically important, and the immutability thing as well.
> We had an agreement last year in TC39 to avoid making new shorter function
> syntax implicitly freeze where the new shorter syntax falls in full
> function syntax's general body-plan. This was the impetus for the # prefix,
> which also can apply to object and array literals.
> We're not going to implicitly freeze arrows. It was never in the strawman,
> or on the whiteboard during the negotiations.
> I agree that leading |this| could be important for dynamic non-method
> use-cases, but those are relatively rare (let's not discount JQuery, but
> again, it could use long functions and survive). We could put
> leading-this-parameterization on the agenda for May, but we'll have to be
> careful not to lose consensus on arrows.
Exactly -- I do remember leading `this' of #-functions, and even talked
myself about it on one of the confs, but I was surprised to see it in
Doug's article on -> functions (now it's clear that it was in wiki as well,
but has been removed).

Notice though, that providing such a Pythonic manual leading `this' just
makes the same manual "this-manipulations", but from the vice-versa side:
In case of normal functions you work implicitly with the dynamic `this',
but should manually capture it using `bind' or saving to a variable if
needed static `this'. In case of -> functions with the leading `this' you
do the same, but capture dynamic `this' -- still manually. Which seems the
same job to do.  I.e. two vice-versa in semantics, but still the same,
function types.

Probably dynamic `this' is really rare in this cases and nobody will use
leading `this', but when people will need it, perhaps it's good to provide
it. Otherwise, they will have to mix different types of functions by
different reasons. In one case a user uses arrow function for shortness, in
other case she should switch to "old-fashion" function expression, because
she says: "hey, I need dynamic `this', but those guys didn't give me such
ability". Lately, I believe users will work out some common patterns and
some of the function types will just die and desperate. The condition for
this -- a function should have all the possible ways of usage/compromises
(short syntax, ability of dynamic/static `this', frozen).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list