Skip to content

[namespace.udecl]/17 Fix the note and comment to better reflect that … #749

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.

Sign up for GitHub

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

Closed
wants to merge 2 commits into from
Closed

[namespace.udecl]/17 Fix the note and comment to better reflect that … #749

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
192f19f
[namespace.udecl]/17 Fix the note and comment to better reflect that …
faisalv Jun 11, 2016
c145057
Don't use x() instead of x, and add a clarifying comment on why the O…
faisalv Jun 12, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions source/declarations.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2921,7 +2921,7 @@
Because a \grammarterm{using-declaration} designates a base class member
(and not a member subobject or a member function of a base class
subobject), a \grammarterm{using-declaration} cannot be used to resolve
inherited member ambiguities. For example,
inherited member ambiguities by itself. For example,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be suggesting that the using-declaration may help when combined with something else. Is that actually true? Can we extend the example to show that, instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose what I was trying to get at was the following:
struct A { int x(); };
struct B : A { int x(B); };
struct C : A { using A::x; int x(C); };
struct D: B, C {
using C::x;
using B::x;
};
D d;
d.x(C{}); // OK - because using declaration helps resolve the inherited member lookup ambiguities
d.x(); // NOT OK - because of conversion of D to base class
d.C::x(); // OK - using declaration brings x() into C's scope and and A is unambiguous base of C which is unambiguous of D

Does this seem reasonable - or should we drop the 'by itself'


\begin{codeblock}
struct A { int x(); };
Expand All @@ -2935,8 +2935,12 @@
using C::x;
int x(double);
};
int f(D* d) {
return d->x(); // ambiguous: \tcode{B::x} or \tcode{C::x}

void f(D* d) {
d->x(); // ambiguous: while member lookup of \tcode{x} in implicit naming class \tcode{D} is unambiguous, the selected
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true regardless of the presence or absence of the _using-declaration_s in this example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes - the using declaration simply helps to guide member lookup so that x() is not hidden.

// overload of \tcode{x} is a direct member of \tcode{A}, which is an ambiguous base of the naming class \tcode{D}
d->C::x(); // OK: the selected \tcode{x} is a direct member of \tcode{A} which is an unambiguous base of the naming class \tcode{C}
// which in turn is an unambiguous base of the object expression's type \tcode{D}
}
\end{codeblock}
\exitnote
Expand Down