Discuss
  • Allow arrow functions with conventional 'function' declarations

Allow arrow functions with conventional 'function' declarations

# Michael Luder-Rosefield (8 years ago)

You're probably asking what on Earth the point of this is, and I'll tell you: hoisting.

My preferred ES5 code style was always to declare functions after their use:

doSomething1();
doSomething2();

function doSomething1 () {
  // ...
}

function doSomething2 () {
  // ...
}

It keeps things uncluttered and readable: you don't have to read through
random functions before they are used, and have to work out what they're
doing there.

If you're able to make use of ES6 arrow functions declared with
`const`/`let`, though, you would have to declare them before use. This
obviously goes against my preferred style, and can also result in
inconsistent placing of function declarations when mixed with conventional
functions.

My proposal is simple: after the initial `function name (params)`, allow
the following forms:
1. { // body code }
2. => { // body code }

3. => // expression ;

1. is of course the current form
2. is similar, except it's a block body arrow function (all the usual arrow
function differences apply; this binding, cannot be used with 'new', no
'arguments', no 'super'...)
3. allows for concise body arrow functions - semi-colon at end.

Example:

// with proposal doSomething1(); doSomething2() .then(doSomething3);

function doSomething1 () { // conventional function }

function doSomething2 () => { // block body arrow function }

function doSomething3 (value) => value ? foo(value) : bar();

// without proposal const doSomething2 = () => { // block body arrow function }; doSomething3 = value => value ? foo(value) : bar();

doSomething1(); doSomething2() .then(doSomething3);

function doSomething1 () { // conventional function }

As you can see, the latter code is just... messy and unpleasant.

I don't think there's any potential issues in  to interpreting
syntax (it just requires a simple check for an arrow after the parameters),
nor with readability. Async We would definitely need to clarify behaviour
with `async` and generator functions, though.
# Michael J. Ryan (8 years ago)

While I appreciate your sentiment, and often relied on housing myself. These days I'd be inclined to continue with the classic funny definition and hosting, or more likely to break it into a separate, testable module.

Not to be contain.