@opensdh, it seems reasonable to define component names of type-specifier and ptr-operator by explicit recursive decomposition. What do you think?

I wrote down to address this in P2449.

In general, I don't think it's all that important, since "a component name of a type-specifier" isn't all that different from "a component name of a thing (which is a simple-type-specifier, elaborated-type-specifier, or typename-specifier) that is a type-specifier". More problematic would be if we defined the component names of a type-specifier and then made use of the component names of (say) a typename-specifier in a context where it was not interpreted as a type-specifier.

That said, the ptr-operator case is a little more serious, since we have to read it as "a component name contained by a ptr-operator" and then we have to worry about how directly it is contained.

Of course, upon rechecking I see that P1787R6 already specified the component names for a ptr-operator!

More problematic would be if we defined the component names of a type-specifier and then made use of the component names of (say) a typename-specifier in a context where it was not interpreted as a type-specifier.

Anyway, the terminal name of a typename-specifier is said to be in type-only context, according to [temp.res.general] p4. if such interpretation is wrong in the instantiation context, it will violate [temp.res.general] p6, especially bullet 6.5.

The basic logic in this issue is a higher-level syntax is a superset of a lower-level syntax, so any properties of the lower-level syntax can be included by the higher-level one but not vice versa. In the first rule, we say the component name of a type-specifier that is a higher-level syntax than anyone in the list, so we should explicitly say what the properties(i.e. component names) of the higher-level syntax are.