Function expression body

[borela]

Similar to C#, when arrow functions were implemented was this idea bought up? If yes, was there any limitations to not allowing this?

export function sum(a, b) => a + b

Sorry if this has been discussed before, I could not find the issue/repo.

[devsnek]

why not just export const sum = (a, b) => a + b

[devsnek]

why not just export const sum = (a, b) => a + b

[borela]

The example I used is too simple just to focus on the syntax, but there are cases where people could benefit from the this not being lexically bound, an example would be class methods like toString.

[borela]

The example I used is too simple just to focus on the syntax, but there are cases where people could benefit from the this not being lexically bound, an example would be class methods like toString.

[ljharb]

If that syntax only worked with exports, it would be very inconsistent to have a special kind of hybrid normal/arrow function that only worked when exported. If that syntax was allowed in general, then we'd have not just normal and arrow functions, but also this kind of hybrid - that's a lot of complexity to avoid a few extra characters ({ return … }).

[ljharb]

If that syntax only worked with exports, it would be very inconsistent to have a special kind of hybrid normal/arrow function that only worked when exported. If that syntax was allowed in general, then we'd have not just normal and arrow functions, but also this kind of hybrid - that's a lot of complexity to avoid a few extra characters ({ return … }).

[borela]

@ljharb Ignore the export or the fact that the function is a simple sum, english is not my mothertongue so I'll stumble a bit when trying to explain.

I was proposing something generic like you said, similar to what happens in C#, which could be used even on methods:

function test() => this.something + 123

let a = {
  myMethod() => `Some complex string: ${this.someVar}`
}

class Test {
  myMethod() => `Some complex string: ${this.someVar}`
}

This was introduced on C# to simplify getters, you can see better examples here: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members

The complexity added is minuscle and it would solve a problem I keep seeing where people are writting arrow functions(because they are smaller) and forgetting about the this semantics only to be baffled that it does not work as expected.

By implementing this, people would only use arrow functions where needed and those who want their code to be smaller, would be able to do so.

I believe, specially after we get private properties for classes, this will help getters to be smaller as this was introduced in C# for this very reason.

I would also argue that it makes function declarations consistent, right now:

• Arrow functions support the => ... as a shorthand for return ...;
• Normal functions doesn't;
• Methods doesn't;

I personally noticed this lack of consistency when I accidentaly wrote a function that returned a complex value using the => only to be reminded by babel that it wasn't allowed.

[borela]

@ljharb Ignore the export or the fact that the function is a simple sum, english is not my mothertongue so I'll stumble a bit when trying to explain.

I was proposing something generic like you said, similar to what happens in C#, which could be used even on methods:

function test() => this.something + 123

let a = {
  myMethod() => `Some complex string: ${this.someVar}`
}

class Test {
  myMethod() => `Some complex string: ${this.someVar}`
}

This was introduced on C# to simplify getters, you can see better examples here: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members

The complexity added is minuscle and it would solve a problem I keep seeing where people are writting arrow functions(because they are smaller) and forgetting about the this semantics only to be baffled that it does not work as expected.

By implementing this, people would only use arrow functions where needed and those who want their code to be smaller, would be able to do so.

I believe, specially after we get private properties for classes, this will help getters to be smaller as this was introduced in C# for this very reason.

I would also argue that it makes function declarations consistent, right now:

• Arrow functions support the => ... as a shorthand for return ...;
• Normal functions doesn't;
• Methods doesn't;

I personally noticed this lack of consistency when I accidentaly wrote a function that returned a complex value using the => only to be reminded by babel that it wasn't allowed.

[ljharb]

This sounds like something you may want to ask es-discuss; see https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md for how to contribute features.

Hopefully someone here can comment on any historical reasoning.

[ljharb]

This sounds like something you may want to ask es-discuss; see https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md for how to contribute features.

Hopefully someone here can comment on any historical reasoning.