Editorial: Remove redundant text in Object Initializer

[gibson042]

Noticed in #3223, with which this has a conflict (trivially addressed by removing the containing <emu-note>).

[michaelficarra]

Why is it safe to move this into a note? These are currently normative requirements. Are they also described elsewhere?

[gibson042]

Yes—in Destructuring Assignment, |LeftHandSideExpression| is refined using |AssignmentPattern|, which uses |ObjectAssignmentPattern| in place of |ObjectLiteral| and |AssignmentProperty| in place of |PropertyDefinition| and therefore never even encounters the nonterminals to which the Early Error rules apply (and likewise for |CoverParenthesizedExpressionAndArrowParameterList| and |CoverCallExpressionAndAsyncArrowHead|).

[jmdyck]

the |ObjectLiteral| productions are also used as a cover grammar for |ObjectAssignmentPattern|

For each of the productions:

  AssignmentExpression : LeftHandSideExpression `=` AssignmentExpression
  DestructuringAssignmentTarget : LeftHandSideExpression
  ForInOfStatement : `for` `(` LeftHandSideExpression `in` Expression `)` Statement
  ForInOfStatement : `for` `(` LeftHandSideExpression `of` AssignmentExpression `)` Statement
  ForInOfStatement : `for` `await` `(` LeftHandSideExpression `of` AssignmentExpression `)` Statement

the spec says:

If |LeftHandSideExpression| is either an |ObjectLiteral| or an |ArrayLiteral|, the following Early Error rules are applied:
-  |LeftHandSideExpression| must cover an |AssignmentPattern|.

Note that AssignmentPattern has 2 alternatives, ObjectAssignmentPattern and ArrayAssignmentPattern.

Given that

• ObjectLiteral and ObjectAssignmentPattern both always start with {, and
• ArrayLiteral and ArrayAssignmentPattern both always start with [,

it's clear that if LeftHandSideExpression is an ObjectLiteral, the covered AssignmentPattern must be an ObjectAssignmentPattern. So, somewhat loosely, we can say that ObjectLiteral production is a cover grammar for ObjectAssignmentPattern.

---

When |ObjectLiteral| appears in a context where |ObjectAssignmentPattern| is required the following Early Error rules are not applied.

The wording of the subordinate clause is a bit odd, it means more like "When an |ObjectLiteral| appears in a context that requires it to cover an |ObjectAssignmentPattern|" (i.e., when it appears as the LeftHandSideExpression in instances of the productions listed above). In those cases, the above early error rule applies, and (roughly speaking) the ObjectLiteral is reparsed as an ObjectAssignmentPattern.

Here, "the following Early Error rules" are rules for PropertyDefinition and ObjectLiteral. Note that a PropertyDefinition can only appear in a PropertyDefinitionList, which can only appear in an ObjectLiteral.

So the quoted sentence is saying that, when an ObjectLiteral is reparsed as an ObjectAssignmentPattern, the rules for ObjectLiteral don't apply. Which makes sense: the ObjectLiteral isn't really an ObjectLiteral, it's just a parsing hack, so it would be weird to subject it to the static rules for ObjectLiterals.

But I don't think we actually say that elsewhere, so I don't think it's safe to move this to a Note.

---

In addition, they are not applied when initially parsing a |CoverParenthesizedExpressionAndArrowParameterList| or |CoverCallExpressionAndAsyncArrowHead|.

This is basically the same idea: a CoverEtc will always be reparsed into something else, so if you've got a CoverEtc that happens to contain an ObjectLiteral, don't apply the ObjectLiteral EE rules (because it might not be an ObjectLiteral in the covered node).

But I don't think we say that elsewhere.

---

Personally, I'd much prefer if, in the definition of "P must cover an N", we also say (something like):
No Early Error rules are applied to _P_ or any of its descendant Parse Nodes.

See issue #2421.

[gibson042]

Personally, I'd much prefer if, in the definition of "P must cover an N", we also say (something like):
No Early Error rules are applied to _P_ or any of its descendant Parse Nodes.

I would be willing to include such a change in either this PR or #3223.

[jmdyck]

I think such a change needs a dedicated PR, so I've created #3227.