Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: Remove redundant text in Object Initializer #3224

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Editorial: Remove redundant text in Object Initializer #3224

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 3 additions & 4 deletions spec.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18399,9 +18399,6 @@ <h2>Syntax</h2>
<emu-note>
<p>|MethodDefinition| is defined in <emu-xref href="#sec-method-definitions"></emu-xref>.</p>
</emu-note>
<emu-note>
<p>In certain contexts, |ObjectLiteral| is used as a cover grammar for a more restricted secondary grammar. The |CoverInitializedName| production is necessary to fully cover these secondary grammars. However, use of this production results in an early Syntax Error in normal contexts where an actual |ObjectLiteral| is expected.</p>
</emu-note>

<emu-clause id="sec-object-initializer-static-semantics-early-errors" oldids="sec-__proto__-property-names-in-object-initializers">
<h1>Static Semantics: Early Errors</h1>
Expand All @@ -18414,7 +18411,9 @@ <h1>Static Semantics: Early Errors</h1>
It is a Syntax Error if PrivateBoundIdentifiers of |MethodDefinition| is not empty.
</li>
</ul>
<p>In addition to describing an actual object initializer the |ObjectLiteral| productions are also used as a cover grammar for |ObjectAssignmentPattern| and may be recognized as part of a |CoverParenthesizedExpressionAndArrowParameterList|. When |ObjectLiteral| appears in a context where |ObjectAssignmentPattern| is required the following Early Error rules are <b>not</b> applied. In addition, they are not applied when initially parsing a |CoverParenthesizedExpressionAndArrowParameterList| or |CoverCallExpressionAndAsyncArrowHead|.</p>
<emu-note>
<p>In addition to describing an actual object initializer the |ObjectLiteral| productions are also used as a cover grammar for |ObjectAssignmentPattern| and may be recognized as part of a |CoverParenthesizedExpressionAndArrowParameterList|. When |ObjectLiteral| appears in a context where |ObjectAssignmentPattern| is required the following Early Error rules are <b>not</b> applied. In addition, they are not applied when initially parsing a |CoverParenthesizedExpressionAndArrowParameterList| or |CoverCallExpressionAndAsyncArrowHead|.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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|).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

</emu-note>
<emu-grammar>PropertyDefinition : CoverInitializedName</emu-grammar>
<ul>
<li>
Expand Down