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 ，后跟=>，后跟误导性的 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

• ConditionalExpression (as in your example)
• YieldExpression
• ArrowFunction
• AsyncArrowFunction
• LeftHandSideExpression = AssignmentExpression
• LeftHandSideExpression AssignmentOperator AssignmentExpression

(您可能会想，像我一样，x = y中的>可以匹配 AssignmentExpression ，因为y显然是 ConditionalExpression  → LogicalORExpression  → LogicalANDExpression  → BitwiseORExpression  → BitwiseXORExpression  → BitwiseANDExpression  → EqualityExpression  → RelationalExpression  → ShiftExpression  → AdditiveExpression  → MultiplicativeExpression  → ExponentiationExpression  → UnaryExpression  → UpdateExpression  → LeftHandSideExpression  → NewExpression → MemberExpression  → PrimaryExpression  → IdentifierReference  → 标识符  — ！ [拖着眉头] .谢谢Oriol！)

(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屋！