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

[namespace.udecl] does not explicitly state the reason for special member hidden #5277

Open
xmh0511 opened this issue Feb 9, 2022 · 0 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Feb 9, 2022

[namespace.udecl] p4 states

If a constructor or assignment operator brought from a base class into a derived class has the signature of a copy/move constructor or assignment operator for the derived class ([class.copy.ctor], [class.copy.assign]), the using-declaration does not by itself suppress the implicit declaration of the derived class member; the member from the base class is hidden or overridden by the implicitly-declared copy/move constructor or assignment operator of the derived class, as described below.

The only possible relevant paragraph referred to by as described below may be [namespace.udecl] p11

The set of declarations named by a using-declarator that inhabits a class C does not include member functions and member function templates of a base class that correspond to (and thus would conflict with) a declaration of a function or function template in C.

Consider this formal example:

struct A{
  A(A &&);
};
struct B:A{
  using A::A;
  B(B const&);
}
extern B b1;
B b2 = static_cast<B&&>(b1);

This case is just clarified by [over.match.funcs#general-9] rather than by [namespace.udecl] itself. [namespace.udecl] p11 requires that two member function should correspond. In this case, A(A &&) does not correspond to B(B const&), as per [basic.scope#scope-4.3]

each declares a function or function template, except when

  • both declare functions with the same non-object-parameter-type-list, equivalent ([temp.over.link]) trailing requires-clauses (if any, except as specified in [temp.friend]), and, if both are non-static members, they have corresponding object parameters, or

They do not have the same non-object-parameter-type-list, thus they do not correspond. So, what does the as described below refer to, for the "copy/move constructor or assignment operator" case?


The definition of corresponds also has a defect for constructors. A constructor is a member function, nonetheless, we never clarify whether such a function is a non-static member function or not through [class.mem#general-4].

A data member or member function may be declared static in its member-declaration, in which case it is a static member (see [class.static]) (a static data member ([class.static.data]) or static member function ([class.static.mfct]), respectively) of the class. Any other data member or member function is a non-static member (a non-static data member or non-static member function ([class.mfct.non-static]), respectively).

So, for a constructor, it falls into the "Any other data member or member function is a non-static member" branch?

This point impacts "if both are non-static members, they have corresponding object parameters" when determining whether two "constructors" correspond. Destructors also have the same issue.

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

1 participant