You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An unqualified name that is a component name ([expr.prim.id.unqual]) of a type-specifier or ptr-operator of a conversion-type-id is looked up in the same fashion as the conversion-function-id in which it appears. If that lookup finds nothing, it undergoes unqualified name lookup; in each case, only names that denote types or templates whose specializations are types are considered.
The rule says these components names are called unqualified names, which has conflicted with [basic.lookup.unqual] p4
An unqualified name is a name that does not follow a nested-name-specifier or the . or -> in a class member access expression ([expr.ref]), possibly after a template keyword or ~. Unless otherwise specified, such a name undergoes unqualified name lookup from the point where it appears.
Consider the example after [basic.lookup.unqual] p5
X().operator U T::*(); // #1X().operator U decltype(T())::*(); //#2
The names U and T in these two expressions all follow . in their class member access expressions. Hence, they shouldn't be unqualified names. Could we change the unqualified name in [basic.lookup.unqual] p5 to name:
A name that is a component name...
Except for that, [basic.lookup.unqual] p5 also does not specify how will the lookup perform on these names that are not component names. Such as the T that appears in decltype(T()) in #2, it is not the component name of neither a type-specifier nor ptr-operator of a conversion-type-id. Which kind of lookup will perform on that name?
The text was updated successfully, but these errors were encountered:
The rule says these components names are called unqualified names
No, the rule says that a certain subset of unqualified names gets special treatment.
So, I see two concerns in treatment of X().operator U decltype(T())::*():
First, your reading of the definition of "unqualified name" and "follow" says that "U" follows the "." in a class member access expression and thus is not an unqualified name. I think the interpretation here is "immediately follow", and we can fix that by saying so.
Applying your suggested change "unqualified name" -> "name" is not good, because we don't want to change the lookup rules for qualified names inside a conversion-type-id.
Second, for decltype(T()), "T" is obviously an unqualified name without a special rule, so "Unless otherwise specified, such a name undergoes unqualified name lookup from the point where it appears." applies.
jensmaurer
changed the title
Component names in converstion-type-id are unqualified names?
[basic.lookup.unqual] Component names in converstion-type-id are unqualified names?
Aug 14, 2021
[basic.lookup.unqual] p5
The rule says these components names are called unqualified names, which has conflicted with [basic.lookup.unqual] p4
Consider the example after [basic.lookup.unqual] p5
The names
U
andT
in these two expressions all follow.
in their class member access expressions. Hence, they shouldn't be unqualified names. Could we change the unqualified name in [basic.lookup.unqual] p5 to name:Except for that, [basic.lookup.unqual] p5 also does not specify how will the lookup perform on these names that are not component names. Such as the
T
that appears indecltype(T())
in#2
, it is not the component name of neither a type-specifier nor ptr-operator of a conversion-type-id. Which kind of lookup will perform on that name?The text was updated successfully, but these errors were encountered: