Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[basic.lookup.unqual] Component names in converstion-type-id are unqualified names? #4812

Closed
xmh0511 opened this issue Aug 14, 2021 · 2 comments · Fixed by #4813
Closed

[basic.lookup.unqual] Component names in converstion-type-id are unqualified names? #4812

xmh0511 opened this issue Aug 14, 2021 · 2 comments · Fixed by #4813
Assignees

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Aug 14, 2021

[basic.lookup.unqual] p5

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::*();  // #1
X().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?

@jensmaurer
Copy link
Member

jensmaurer commented Aug 14, 2021

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 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
@jensmaurer jensmaurer self-assigned this Aug 14, 2021
@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 16, 2021

Yes, just "immediately follow" would clean the two concerns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants