Identity cover grammar

[waldemarhorwat]

The CoverAwaitExpressionAndAwaitUsingDeclarationHead and AwaitExpression grammars are identical, so I'm curious about the editorial decision to reparse in that case.

The proposal includes instances of static semantics reparsing a CoverAwaitExpressionAndAwaitUsingDeclarationHead as an AwaitExpression, and generating an error if that fails, but it can't fail.

I assume the reason to keep the cover conceptually separate from the identical covered grammar is so that assertions like that in AwaitExpression work cleanly; if so, an informative note might be in order.

[rbuckton]

@syg, @michaelficarra, @bakkot do you have thoughts on this? Is it worth leaving the cover in?

[syg]

I was similarly confused by this. I think even had to ask @rbuckton to explain why it's the same grammar. Definitely worth at least a note. I think on net, having an identical-in-content-but-differently-named production is a positive on readability. I don't know of a better way to do it in any case.

[waldemarhorwat]

If all you want is an identical-in-content-but-differently-named production, you might not need a cover grammar. A production that expands to another production might work.

[rbuckton]

We do something similar to this in the spec already in that CoverCallExpressionAndAsyncArrowHead is identical to CallMemberExpression. IIRC, the only places where we use a production as both the actual production and as a cover for a different production are ArrayLiteralExpression and ObjectLiteralExpression.

In my opinion, calling it out as a cover makes it more obvious to the spec reader that the syntax has other implications to consider.