Repository navigation
[temp.res.general] p5: dependent names in other than type-only context #4792
Description
Activity
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.
However, [temp.res#general-4] is saying so, that is
A qualified or unqualified name is said to be in a type-only context if it is the terminal name of
- [...]
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.
@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?
- changed the title
[-][temp.res#general-5] Not precise[/-][+][temp.res.general] p5: dependent names in other than type-only context[/+]on Aug 4, 2021 AFAIK, the term qualified name has a formal definition, which is defined in [basic.lookup.qual#general-2]
A qualified name is
- a member-qualified name or
- the terminal name of
- a qualified-id
- [...]
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.
Given this clarification, the original issue here (add "if and only if") seems plausible; what do you think?
I think this rephrasing is an improvement, although this section is going to get rewritten for the "non-expression qualified-id" issue anyway.
Consider the first sentence in [temp.res#general-5]
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
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.