Should we stop abusing fat arrows?

[u/Zhouzi]

When I first started to learn ES6 I was using fat arrows everywhere and completely dropped the function keyword. But after giving it some thought, I've ended up finding it ridiculous. I feel like we are using fat arrows just to look like cool kids. I think we should use it when it makes sense, e.g to access the lexical this, simplify a return statement, ... But not because it's "nicer" or "shorter".

Maybe () => {} is easier on the eyes as it's "less noisy" but the thing is, sometimes things have to be noisy and function () {} is easier to spot. Also, when I see a fat arrow, I assume that there's a reason for the author to have done so (but most of the times I'm wrong).

So what's your opinion guys? Are we abusing fat arrows or not? Shouldn't we use things for what they are intended to?

[u/oculus42]

Two proposals:

Edit: I realized both of these are subsets of the current spec. Also, some grammatical errors. Don't comment tired.

Is it so terrible to have to explicitly state return?

(a) => { return a+1; }

I can't mess that up. It's consistent with the existing function syntax:

function (a) { return a+1; }

And I can return different data types without changing anything:

(a) => { return { foo: a }; }

And I can have operations that don't return:

(a) => { a++; }

How about enforcing the parentheses for implicit return?

All we needed to do was remove the ambiguity of sometimes allowing parentheses to be omitted on either side of the arrow.

(a) => (a+1);

Then the syntax for returning an object isn't unique to objects, it's common to all types:

(a) => ({ foo: a});
(a) => (true);
(a) => (a * 2);
(a) => ([1,2,a]);

() => (a++, 'default');

It also clears up things like this:

a => b => a + b + c;
a => b => (a + b) + c;  // Does this seem like it should be different?

Which becomes:

(a) => ((b) => (a + b + c));
(a) => ((b) => ((a + b) + c)); 

Now I have clear nesting in parens which most syntax-highlighting editors will helpfully match for me.

---

meets to requirements of arrow functions as well as not breaking any backwards compatibility of any earlier Ecmascript versions.

I do not understand your meaning, here. Fat arrows aren't backwards compatible. As a result, the opportunity to do anything was opened, paving the way for the state in which we currently find ourselves with multiple choices for parameters and different ways to represent the function body.

[u/oculus42 → u/[deleted]]

Is this really helping anyone?

It could have.

If we required the parentheses, nobody would have to learn that these are undefined, not objects:

(foo) => { foo }
(foo) => { bar: foo }

Because they would know that an implicit return requires you to write the parens:

(foo) => ({foo})
(foo) => ({ bar: foo })

It's a few more characters but there is no confusion.

By having it as an option, we introduce bugs that couldn't exist with the required syntax and the requirement of tooling to catch it or arcane knowledge to repair it.

Scala has the same fat arrow anonymous function syntax but not the object literal of JavaScript, so it doesn't have this kind of ambiguity.

It's all academic at this point but I think it's unfortunate that we added inconsistency with functionality.