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

Derived constructor is not preferred, rather the base constructor does not belong to the set of candidate. #2524

Closed
Kannen opened this issue Nov 26, 2018 · 1 comment

Comments

@Kannen
Copy link
Contributor

Kannen commented Nov 26, 2018

In [namespace.udecl], inside a note, it is written:

A constructor of a derived class is sometimes preferred to a constructor of a base class if they would otherwise be ambiguous ([over.match.best]).

Which suggests that the derived constructor is selected as part of the selection of the best viable function. But I have found nothing in [over.match.best] related to inherited constructor.

The only rule I found is in [over.match.func]/8:

A constructor inherited from class type C ([class.inhctor.init]) that has a first parameter of type “reference to cv1 P” (including such a constructor instantiated from a template) is excluded from the set of candidate functions when constructing an object of type cv2 D if the argument list has exactly one argument and C is reference-related to P and P is reference-related to D.

So I think that in [namespace.udecl] the should be closer to:

An inherited constructor with a single argument, depending on this argument type, may not participate to overload resolution ([over.match.func]).

@zygoloid
Copy link
Member

http://eel.is/c++draft/over.match.best#1.9:

a viable function F1 is defined to be a better function than another viable function F2 if [...] F1 is a constructor for a class D, F2 is a constructor for a base class B of D, and for all arguments the corresponding parameters of F1 and F2 have the same type

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

No branches or pull requests

2 participants