We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Arthur O'Dwyer posted the following examples to the reflector:
Would be really helpful to add some version of these examples to that clause to make it clear what the rule is.
The text was updated successfully, but these errors were encountered:
@opensdh , could you please check these examples?
I think for the first example, we look in A first and find T=int. Same for the second example, we get U=U1 and T=T1.
If you agree, I'll turn this into examples for [basic.lookup.unqual] p5.
Sorry, something went wrong.
I think for the first example, we look in A first and find T=int.
Yes, and this is true even if A is a dependent type.
A
Same for the second example, we get U=U1 and T=T1.
Yes, both of those are relevant component names ([basic.lookup.unqual]/5 explicitly names "type-specifier or ptr-operator"). Note in that example that
operator T1::U() { return {1}; } operator T2::U() { return {2}; }
are irrelevant.
Thanks!
jensmaurer
Successfully merging a pull request may close this issue.
Arthur O'Dwyer posted the following examples to the reflector:
Would be really helpful to add some version of these examples to that clause to make it clear what the rule is.
The text was updated successfully, but these errors were encountered: