Discuss
  • arrow functions and dart

arrow functions and dart

# Francisco Ferreira (11 years ago)

Just to set some expectations, Although I follow es-discuss, I read more than I discuss. So the point I want to achieve with this e-mail is:

I have played with dart since it was in alpha. And I also have been coding with --harmony for a while. I would like to comment that arrow functions in dart are much better than in ES6 (mozilla implementation).

Let's compare

In JS: anObject.thatGetsACallback( (arg1, arg2) => { .... } );

In dart: anObject.thatGetsACallback( (arg1, arg2) { .... } );

It seems much less invasive and it contains less characters. So my question to es-discuss is: what is the current discussion regarding removing the arrow for anonymous inline functions. Can we still dial back, and look at the dart approach for inline functions?

Btw, overall discussions are awesome!

# Rick Waldron (11 years ago)

On Mon, Sep 22, 2014 at 5:18 PM, Francisco Ferreira < francisco.m.s.ferreira at gmail.com> wrote:

Hi,

Just to set some expectations, Although I follow es-discuss, I read more than I discuss. So the point I want to achieve with this e-mail is:

I have played with dart since it was in alpha. And I also have been coding with --harmony for a while. I would like to comment that arrow functions in dart are much better than in ES6 (mozilla implementation).

Let's compare

In JS: anObject.thatGetsACallback( (arg1, arg2) => { .... } );

In dart: anObject.thatGetsACallback( (arg1, arg2) { .... } );

Sure, but that syntax cannot be used outside of call expression arguments. I had a proposal in 2011 (gist.github.com/rwaldron/961495) that fell down on this hazard:

var x = 1; f = (x) { x }

...Which is a valid JavaScript program today, which means that (params){ body } cannot parse unambiguously.

# Matthew Robb (11 years ago)

I think it's also worth noting that CoffeeScript uses an arrow as well and it doesn't seem to impact usability much if at all.

  • Matthew Robb
# Salvador de la Puente González (11 years ago)

Proposal:

x, y : x*y;

or...

x, y : { //body... }

or the sharp alternative from Brendan [1]

#(x, y) { body... }

I find first option very interesting as it is very tiny for simple lands lambdas but allowing bigger bodies and with non ambiguous syntax.

[1] brendaneich.com/2011/01/harmony-of-my-dreams

# Caitlin Potter (11 years ago)

We already have two (three? not sure about JSC) engines which implement arrow functions, plus Traceur. It seems silly to talk about changing the syntax at this point when people have shown they’re already happy with the arrow.

The suggestions shown here, apart from the last item, look pretty ambiguous (and therefore harder to parse). For instance, x, y : x*y already looks like a shorthand property + a plain data property with a value computed when the object is instantiated. x, y : { // body } looks like a shorthand property + a data property which happens to be an object literal. I guess the #(x, y) could work, but what’s the point of changing the syntax around again?

Caitlin Potter caitpotter88 at gmail.com

# Russell Leggett (11 years ago)

We already have two (three? not sure about JSC) engines which implement arrow functions, plus Traceur. It seems silly to talk about changing the syntax at this point when people have shown they’re already happy with the arrow.

Agreed. This is basically bikeshedding after the bike shed has been built. Surely there are other areas you could give your attention/feedback to.

# Salvador de la Puente González (11 years ago)

Yep. I didn't remember shortcut properties.

Anyway, don't worry about discussions. If it's not interesting, it simply won't go any further. There is always room for improvements.

# John Lenz (11 years ago)

On Tue, Sep 23, 2014 at 4:19 AM, Caitlin Potter <caitpotter88 at gmail.com>

wrote:

We already have two (three? not sure about JSC) engines which implement arrow functions, plus Traceur.

And Closure Compilers' ES6 -> ES5 support. :-). (shameless plug)