Repository navigation
[temp.res.general] p5: dependent names in other than type-only context #4792
Description
Consider the first sentence in [temp.res#general-5]
A qualified-id whose terminal name is dependent and that is in a type-only context is considered to denote a type.
How about the otherwise case? if the terminal name is not in a type-only context, whether it may denote a type or it definitely does not denote a type? It's difficult to infer the meaning of the otherwise cases from the current sentence.
Is it more clear if we change it to that
A qualified-id whose terminal name is dependent is considered to denote a type if and only if its terminal name is in a type-only context.
In this sentence, the subtext means the qualified-id can never denote a type if the dependent terminal name is not in a type-only context. This subtext also conforms to the intent of the standard.
Activity
jensmaurer commentedon Aug 4, 2021
I think we mean that the qualified-id needs to be in a type-only context, not just its terminal name. Any rephrasing should retain that meaning.
xmh0511 commentedon Aug 4, 2021
However, [temp.res#general-4] is saying so, that is
In other words, the qualified or unqualified name first refers to the terminal name of something and we say they are in a type-only context if the terminal name(qualified or unqualified name) satisfies some conditions. The meaning is more clear in [basic.lookup.qual#general-2]. On another hand, if a terminal name of something is in that context, of course, the something that comprises the name is also in that context.
jensmaurer commentedon Aug 4, 2021
@opensdh, regarding [temp.res.general] p4:
I think it doesn't make sense to claim that a terminal name can be qualified; the rules for "terminal name" would kill any qualification. If you agree, p4 should just say "A name is said to be in a type-only context if it is the terminal name of ..."
UPDATE: I'm confused. "qualified name" is different from qualified-id. The wording does make sense as-is, but I'd still just say "name".
Given this clarification, the original issue here (add "if and only if") seems plausible; what do you think?
[-][temp.res#general-5] Not precise[/-][+][temp.res.general] p5: dependent names in other than type-only context[/+]xmh0511 commentedon Aug 4, 2021
AFAIK, the term qualified name has a formal definition, which is defined in [basic.lookup.qual#general-2]
In other words, the terminal name of one of the components in the list is called a qualified name, IMO, [temp.res.general] p4 seems to have no problem(a qualified name is the terminal name of ...), at least, there is no conflict here.
In addition, [temp.res.general] p4 in most respects is saying the terminal name of a qualified-id(even if it should be a simple-type-specifier on grammar), which is another #4791 issue.
opensdh commentedon Aug 31, 2021
I think this rephrasing is an improvement, although this section is going to get rewritten for the "non-expression qualified-id" issue anyway.
xmh0511 commentedon Aug 31, 2021
@opensdh For "non-expression qualified-id", the rewritten content is #4793