Oops - correction:

The grammar rule "additive-expression: multiplicative-expression" means that any sequence of tokens which can parse as a multiplicative-expression could also parse as an additive-expression, but it does not mean that every multiplicative-expression in a parse tree is also an additive-expression.

On Sun, Sep 22, 2019 at 2:40 PM Andrew Schepler <aschepler@gmail.com> wrote:


`1` is certainly an *expression* (the grammatical production) and normal English word "expression" as used in the standard.

literal > primary-expression > postfix-expression > unary-expression > cast-expression > pm-expression > multiplicative-expression > additive-expression > shift-expression > compare-expression > relational-expression > equality-expression > and-expression > exclusive-or-expression > inclusive-or-expression > logical-and-expression > logical-or-expression > conditional-expression > assignment-expression > expression

I don't agree. The token "1" can be a grammatical _expression_, but it's not when appearing in the context "f(n+1);". The grammar rule "multiplicative-expression: additive-expression" means that any sequence of tokens which can parse as an additive-expression could also parse as a multiplicative-expression, but it does not mean that every additive-expression in a parse tree is also a multiplicative-expression. We also have the rule "simple-capture: this", but we wouldn't say every instance of the keyword "this" is a simple-capture, only the ones which are used as the "simple-capture" symbol in the right side of some parent rule.

And using a grammar symbol to mean any sequence of tokens, or even any sequence of tokens associated with a node in the grammar tree, which "could be parsed" as that symbol would make things worse: the tokens "int()" can be a postfix-expression or a type-id, but never both. Sometimes the grammar alone forces those tokens to be one or another, and in several other places an explicit disambiguation rule is needed, but clearly even in the cases where no disambiguation is mentioned, being a valid parse is not enough to make the tokens a postfix-expression or type-id.