Javascript 中箭头函数 (fat arrow =>) 的确切解析优先级是什么? [英] What is the exact parsing precedence of arrow function (fat arrow =>) in Javascript?

问题描述

我从 eslint 文档 中看到了一个关于箭头函数的例子:>

I came across an example from eslint documentation on arrow function:

// The intent is not clear
var x = a => 1 ? 2 : 3;

所以我研究了一些关于箭头函数的优先级.似乎 => 不被视为运算符，因为它在 MDN 上的运算符优先级表.从页面 箭头函数，它说

So I researched a bit regarding the precedence of arrow functions. It seems that => is not considered an operator, as it cannot be found on the table of operator precedence on MDN. And from the page arrow functions, it says that

箭头函数具有特殊的解析规则，与常规函数相比，它们与运算符优先级的交互方式不同.

arrow functions have special parsing rules that interact differently with operator precedence compared to regular functions.

但它没有进一步详细说明特殊解析规则.所以我的问题是，关于箭头函数的优先规则是什么?

But it does not further elaborate on the special parsing rules. So my question is, what is the rule of precedence regarding arrow functions?

根据我的测试，它的优先级似乎高于赋值，但低于条件(三元)运算符?

Based on my test, it seems that its precedence is higher than an assignment, but lower than the conditional(ternary) operator?

var x = 0, a = 5;
console.log(x = a => 1 ? 2 : 3);
// same as x = (a => (1 ? 2 : 3))
console.log(x);
console.log(a);

但我不确定这在不同的浏览器和平台上是否一致.任何人都可以对这种行为给出明确的答案吗?

But I'm not sure if this is consistent on different browsers and platforms. Can anyone give a definitive answer to this behavior?

推荐答案

如您所说，=> 不是运算符.箭头函数是主要语法.

As you say, => is not an operator. Arrow functions are primary syntax.

规范中定义了它们的规则，从 ArrowFunction 制作.ArrowFunction 被定义为 ArrowParameters 后跟 => 后跟误导性命名的 ConciseBody.ConciseBody 有两种形式.您正在询问使用 ExpressionBody 的表单，其中是 => 不是 { 之后的第一个非空白标记.如果那里有一个左花括号，它将表示一个名为 FunctionBody 的块的开头.

The rules for them are defined in the specification, starting with the ArrowFunction production. ArrowFunction is defined as ArrowParameters followed by => followed by the misleadingly-named ConciseBody. ConciseBody has two forms. You're asking about the form using ExpressionBody, which is where the first non-whitespace token after => isn't {. If there were an opening curly brace there it would denote the opening of a block called a FunctionBody instead.

ExpressionBody 的定义非常简单:它是一个 AssignmentExpression.

这让我们进入了非常熟悉的领域，因为 AssignmentExpression 是赋值(或变量初始值设定项)右侧的语法、数组初始值设定项中的条目、属性的值部分初始值设定项、函数的参数等.因此，在简洁的正文中 => 后面的内容与我们在下面的 AssignmentExpression 中放置的内容具有相同的解析规则:

Which takes us into very familiar territory, because AssignmentExpression is the syntax for the right-hand side of an assignment (or variable initializer), entries in an array initializer, the value part of a property initializer, an argument to a function, etc. So whatever follows the => in a concise body has the same parsing rules as what we put where AssignmentExpression is below:

x = AssignmentExpression;
y = AssignmentExpression, z = AssignmentExpression;
a1 = [AssignmentExpression];
a2 = [AssignmentExpression, AssignmentExpression];
o1 = {foo: AssignmentExpression};
o2 = {foo: AssignmentExpression, bar: AssignmentExpression};
doSomething(AssignmentExpression);
doSomething(AssignmentExpression, AssignmentExpression);

只是为了详细说明，AssignmentExpression 是:

Just for detail, an AssignmentExpression is any of:

• ConditionalExpression(如您的示例)
• YieldExpression
• ArrowFunction
• AsyncArrowFunction
• LeftHandSideExpression = AssignmentExpression
• LeftHandSideExpression AssignmentOperator AssignmentExpression

(您可能想知道，正如我所做的，x = y 中的 y 可以匹配 AssignmentExpression 给定上面的定义，因为 y 显然是一个 Identifier 并且这些看起来都不会导致 Identifier 生产.这是规范可能真的很难阅读的地方.事实证明，如果你坚持足够长的时间，你就会到达那里.路径是(深呼吸):AssignmentExpression →ConditionalExpression →LogicalORExpression →LogicalANDExpression →BitwiseORExpression →BitwiseXORExpression →BitwiseANDExpression →EqualityExpression →RelationalExpression →ShiftExpression →AdditiveExpression →MultiplicativeExpression →ExponentiationExpression →UnaryExpression →UpdateExpression →LeftHandSideExpression →NewExpression →MemberExpression →PrimaryExpression →IdentifierReference →标识符 —哇！[抹眉].谢谢奥利奥！)

(You may wonder, as I did, how the y in x = y can match AssignmentExpression given the definition of it above, since y is clearly an Identifier and none of those looks like it will lead to the Identifier production. This is where specs can be really hard to read. It turns out that you get there if you keep going long enough. The path is (deep breath): AssignmentExpression → ConditionalExpression → LogicalORExpression → LogicalANDExpression → BitwiseORExpression → BitwiseXORExpression → BitwiseANDExpression → EqualityExpression → RelationalExpression → ShiftExpression → AdditiveExpression → MultiplicativeExpression → ExponentiationExpression → UnaryExpression → UpdateExpression → LeftHandSideExpression → NewExpression → MemberExpression → PrimaryExpression → IdentifierReference → Identifier — whew! [mops brow]. Thank you Oriol!)

这篇关于Javascript 中箭头函数 (fat arrow =>) 的确切解析优先级是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！