Eliminate the `=` in Arrow Functions

If the whole point of arrow syntax is to simplify, then it's too complicated.

Currently, the rule is:

  • If there's ONE parameter, you may omit the parens.
  • But, if there's NO parameter, you MUST include the parens.

Am i the only person who considers this completely non-intuitive and illogical? This strikes me as forcing the programmer to pander to a dumb parser, instead of making the parser smarter.

The parameter list for a function with no parameters should NOT be written.
Eliminate the =

Suggestion:
Instead of:
var f = () => ...

it should be:
var f => ...

I'd further like to suggestion removing the = completely, whether or not there are any params. Requiring the equal-sign means you HAVEN'T replaced function with =>. It means you replaced function with = =>.

Instead of:
var f = (myParameter) => ...

it should be:
var f (myParameter) => ...

1 Like

If you consider "you can omit the arg parens only if you have one non-destructured non-defaulted argument" unintuitive and illogical, why would you want to make the otherwise simple rule "0, 1, or N args are wrapped in parens" more complex?

I'm not sure how saving 5 characters (less if you don't count whitespace) is worth the added complexity of yet another way to write functions and declare variables.

1 Like

"0, 1, or N args are wrapped in parens"

  • My understanding is that 1 arg ISN'T wrapped in parens, optionally. The reason for that is to reduce typing when there's only 1 parameter. So, 1 arg, parens are optional. 0 args, parens are required. It's inconsistent.

"I'm not sure how saving 5 characters (less if you don't count whitespace) is worth the added complexity of yet another way to write functions and declare variables."

  • My suggestion *isn't "*another way to declare variables". You're misrepresenting my suggestion.

  • My suggestion isn't "to save 5 characters (less if you don't count whitespace)". It's to save many more characters than that, with the big-arrow syntax, compared to traditional function syntax. Imo, if saving characters was part of the motivation for introducing big-arrow, then why not do it thoroughly and consistently?

  • If JS is going to continue to be the Lingua Franca of contemporary programming, let's make it better.

  • If you're opposed to "yet another way to write functions", then you're probably not a fan big-arrow syntax, which is "another way to write functions". So, you're probably opposed to improving the language in general. Therefor, maybe you should post an idea that says: "Roll back JS to ES5 or earlier, remove the 'Idea' tag on this forum, shutdown the forum, and stop trying to fix JS."

  • This suggestion is intended for people who are receptive to suggestions, open to change, and willing to acknowledge the language has flaws, holes, and inconsistencies.

Arrow functions can do one big thing function functions can't: they can call both super(...) and super.foo within the context of a class constructor or class method, respectively. They also have no prototype, making them slightly lighter in practice to construct.

Also keep in mind: @ljharb was behind several features of ES2015. In fact, he's one of the people who pushed for arrow functions to provide some material functionality beyond the standard ES5 functions, including both the this capturing and the super capturing IIRC.

That’s not actually true, i joined TC39 just before ES2015 was finalized, and had little to do with its design.

That said, yes, arrow functions are not just sugar for normal functions, they’re a different kind of function.

I'll stand corrected, then. I thought I saw you involved in those, but I must have mistaken you for someone else. I do recall someone fighting to ensure that, though, and it's very much something I would've expected you to do, to be fair.

i'm unclear how that rebuts my suggestion to lighten the syntax of a feature which exists to lighten syntax, nor my assertion that 1 arg isn't wrapped in parens.

It's not "fair" to make false statements.