Identity cover grammar
Opened this issue · 4 comments
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.
@syg, @michaelficarra, @bakkot do you have thoughts on this? Is it worth leaving the cover in?
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.
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.
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.