Single destructuring argument to an arrow function
Inline...
On Thu, Mar 19, 2015 at 4:50 PM Jan-Ivar Bruaroey <jib at mozilla.com> wrote:
Hi group! First post, so be gentle.
Welcome
I love how arrow functions allow single arguments to be passed without parenthesis, so I expected this to work:
Promise.all([true, false]).then([foo, bar] => console.log(foo +”,
"+ bar));
but it doesn't:
SyntaxError: invalid arrow-function arguments (parentheses around
the arrow-function may help)
I understand from the spec that this is as defined, but is there a technical reason to disallow it?
To prevent ambiguity with:
MemberExpression Arguments CallExpression Arguments
Arguments[Yield] : ( ) ( ArgumentList[?Yield] )
ArgumentList[Yield] : AssignmentExpression[In, ?Yield] ... AssignmentExpression[In, ?Yield] ArgumentList[?Yield] , AssignmentExpression[In, ?Yield] ArgumentList[?Yield] , ... AssignmentExpression[In, ?Yield]
e.g.
fn([a, b])
But we could extend the cover grammar with some work. You'd have to push ArrayLiteral and ObjectLiteral down from PrimaryExpression alternative right-hand sides, to live under CoverParenthesizedExpressionAndArrowParameterList.Seems do
Really awesome if we could have this feature.
But we could extend the cover grammar with some work. You'd have to push ArrayLiteral and ObjectLiteral down from PrimaryExpression alternative right-hand sides, to live under CoverParenthesizedExpressionAndArrowParameterList.Seems do-able -- anyone see a fatal problem?
Not for ES6 arrows, but it might be an issue for ES7-proposed async arrows:
async [ a, b ] => { }
async { a, b } => {}
Still technically do-able I think, but you'd have to cover bracketed member expressions in addition to the identifier + arguments that we already need to cope with. (More cover grammars, belch...)
First post, so be gentle.
I love how arrow functions allow single arguments to be passed without parenthesis, so I expected this to work:
"+ bar));
but it doesn't:
the arrow-function may help)
I understand from the spec that this is as defined, but is there a technical reason to disallow it?
The parenthesis seem redundant to the naked eye.
Thanks,
.: Jan-Ivar :.