arrow syntax unnecessary and the idea that "function" is too long

Brendan Eich brendan at mozilla.com
Tue May 17 17:30:05 PDT 2011


On May 17, 2011, at 5:04 PM, Kyle Simpson wrote:

> Regarding the -> and => syntax, I just want to throw out one other concern that I hope is taken into account, not only now, but for the future: I really hope that we don't get to the point where we start adding functionality to that style of function that is not available to explicit functions (we're almost, but not, there with having => do the magical `this` binding).

You have to distinguish syntax from semantics.

There's nothing proposed for arrow functions that is more than "shorter syntax" -- including |this| binding.


> I know Brendan and others have declared it's "shorthand only", but it can be a slippery slope, and to rely on the "if you don't like -> don't use it" argument, we have to make sure that it really stays only a shorthand and nothing more, otherwise it's tail-wagging-the-dog.

Agreed, which is why I'm still going to write up a fairy radical Ruby-block proposal that competes in this sense: it too gives "better function syntax", plus semantics not available to arrow functions as constrained to be "just syntax".

I hope we'll be able to decide between these two approaches quickly, since I do not want to "do both". That is, either arrow functions win and shorter syntax is enough; or we have blocks for control abstraction (which means other syntax changes, details soon) and no arrow functions.


> In other words, I hope that those who favor -> aren't also hoping that eventually -> replaces `function` entirely. As stated many times thus far in this thread, there are still those of us who favor (and maybe always will) the explicitness of `function(){}` or `#(){}`.

There's no way to remove 'function' long syntax from JS. Just no way.

Your point about "just syntax" is well-taken, since translation tools will be important in aiding Harmony migration -- not just for targeting downrev browsers but for added static checking -- and these should be as simple (local rewriting, e.g. transpilers not compilers) as possible.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110517/b085e547/attachment.html>


More information about the es-discuss mailing list