Clarify naming around paren expressions #3444
Conversation
(Split out of carbon-language#3410) Consistently use `ParenExpr` solely for parenthesized single expressions, and use more syntax-oriented terminology for states and nodes that might represent either a `ParenExpr` or a tuple literal.
| // ( ... ) | ||
| // ^ |
There was a problem hiding this comment.
Can this occur on TupleLiteralElementFinish? Should it be removed or replaced with something like ( ... , ... ) pointing to the close )?
There was a problem hiding this comment.
You may be right that at the moment the "..." always contains a comma, but that's not an invariant that HandleTupleLiteralElementFinish either enforces or relies on; it's just a contingent fact about how this state is currently used. In particular, if we chose to reimplement CallExpr in terms of TupleLiteral, that would no longer be true, and as far as I know, nothing about TupleLiteralElementFinish itself would need to change to accommodate that. As a result, I don't see much benefit to narrowing its contract in that way.
| // On a comma, push another expression handler. | ||
| if (list_token_kind == Context::ListTokenKind::Comma) { |
There was a problem hiding this comment.
I found this confusing, given that we always have a comma in this case.
| // On a comma, push another expression handler. | |
| if (list_token_kind == Context::ListTokenKind::Comma) { | |
| // If the close paren is not next, push another expression handler. | |
| if (list_token_kind != Context::ListTokenKind::CommaClose) { |
There was a problem hiding this comment.
Done, but with some other comment changes in light of your other comment.
(Split out of #3410)
Consistently use
ParenExprsolely for parenthesized single expressions, and use more syntax-oriented terminology for states and nodes that might represent either aParenExpror a tuple literal.