[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.]

There are at least a couple of problems in the description of the various id-expressions in _N4567_.5.1.1 [expr.prim.general]:

1. Paragraph 4 embodies an incorrect assumption about the syntax of qualified-ids:

   The operator :: followed by an identifier, a qualified-id, or an operator-function-id is a primary-expression.

   The problem here is that the :: is actually part of the syntax of qualified-id; consequently, “:: followed by... a qualified-id” could be something like “:: ::i,” which is ill-formed. Presumably this should say something like, “A qualified-id with no nested-name-specifier is a primary-expression.”

2. More importantly, some kinds of id-expressions are not described by _N4567_.5.1.1 [expr.prim.general]. The structure of this section is that the result, type, and lvalue-ness are specified for each of the cases it covers:

   • paragraph 4 deals with qualified-ids that have no nested-name-specifier

   • paragraph 7 deals with bare identifiers and with qualified-ids containing a nested-name-specifier that names a class

   • paragraph 8 deals with qualified-ids containing a nested-name-specifier that names a namespace

   This treatment leaves unspecified all the non-identifier unqualified-ids (operator-function-id, conversion-function-id, and template-id), as well as (perhaps) “:: template-id” (it's not clear whether the “:: followed by a qualified-id” case is supposed to apply to template-ids or not). Note also that the proposed resolution of issue 301 slightly exacerbates this problem by removing the form of operator-function-id that contains a tmeplate-argument-list; as a result, references like “::operator+<X>” are no longer covered in _N4567_.5.1.1 [expr.prim.general].