[expr.ref] Remove redundant bullet

[lprv]

E2 is grammatically an id-expression, which can't denote a type.

[jensmaurer]

A grammatical "id-expression" might not be an expression, because it has not been "suitably declared". Which is fine, because E2 does not need to be (and sometimes isn't) a valid expression in its own right, for example when E2 names a pseudo-destructor or an overload set.

[lprv]

I'm not sure I understand. If E2 resolves to a type name, then it has not been suitably declared, and since it is not appearing as part of a declarator-id either, it is not an id-expression and thus can't be the right operand of a class member access. (Pseudo-)destructors are not denoted by (plain) identifiers and so are not covered by the "suitably declared" rule; overload sets are mentioned in [expr.prim.id.general] so I would think that should count as being suitably declared (although there seems to be some redundancy between [expr.prim.id.general]/5 and [expr.ref]/7.3). Where is my interpretation going wrong?

Looking at it a bit more, I think there might be a bug in the wording here: the "suitably declared" rule appears under "Unqualified names" and talks about identifiers being id-expressions, but we probably want qualified names to be treated similarly (std::string + 42 should not be a valid expression).

[jensmaurer]

(The "suitably declared" rule was a digression, I think. Sorry.)

An id-expression grammatically appears as a part of a declarator-id. There, it is not an expression in the sense of [expr]. However, the rules in [expr.prim.id.general] do not differentiate between id-expression used in a declarator-id and those used in expression contexts (such as stand-alone or as part of a class member access). Maybe they should.

Also note that overload resolution is not directly applied to the id-expression appearing in a class member access, but to the entire class member access expression (for example, E1 defines the implicit object argument).

Given this mess, I'm not agreeing to editorially remove normative words for class member access.

My preferred path forward is to introduce separate grammar non-terminals for the thing that appears in a declarator-id, for the thing that is E2 in a class member access, and for the thing that is one option of a primary expression. That would properly scope some of the rules we have, at which point we might be able to remove the "nested type" bullet you seek to strike. Such an effort would need CWG review, though.