[class.copy.ctor] Class.copy.ctor doesn't distintuish between two class types formed inside a class template

[ranaanoop]

Full name of submitter: Anoop S. Rana

Reference (section label): class.copy.ctor

Link to reflector thread: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101113

Issue description: Consider the following program that is rejected by gcc and clang but accepted by msvc. The intention seems to make it ill-formed as also discussed in the old gcc bug report that also says this should/is ill-formed. Demo

//let's call this program 1
#include <concepts>

template <typename T>
class A {
    A(A<void>) requires (!std::same_as<void, T>){}
};

In class.copy.ctor we have:

A declaration of a constructor for a class X is ill-formed if its first parameter is of type cv X and either there are no other parameters or else all other parameters have default arguments. A member function template is never instantiated to produce such a constructor signature.

It isn't clear how the above quoted reference from class.copy.ctor says that the class types X<T> and X<void> are same. I mean for the class template A in our example, the copy ctor should be formed using X<T> and not X<void> so that the ctor version with X<void> parameter can be a parameterized ctor with a parameter of type X<void> and not a copy ctor. I mean it depends on what T will be. We can already have program like this:

//let's call this program 2
template <typename T>
struct A {
     
    A(A<T>&){
        std::cout << "inside A<T>" ;
    }
    A(A<void>&){std::cout << "inside A<void>";}
    
    A(){std::cout << "inside default ctor\n";}
};
void f(A<int>)
{

}
 A<int> i;
 int main()
 {
    f(i); //calls A<T> version 
 }

where the output depends on which class tempalte we instantiate. So the program 1 should also work depending upon T instead of not work for all types. I mean in program 2 it is clear the T will determine which version to use so why isn't T also determining the result in case of program 1. One reason might be to reduce complexity of the language wording etc the wording is so choosen for reason like the ill-formedness should not depend on T but that doesn't make much sense to me.

Suggested resolution: We should add wording to make this well-formed depending on T instead of putting a blanket ban for all T.

[cpplearner]

The problem isn't that A<T> may be the same as A<void>. This doesn't make the program ill-formed in itself. It's that the presence of function definition of A(A<void>) means the parameter type A<void> must be complete, which leads to the instantiation of A<void>.

So it actually has something to do with [dcl.fct.def.general]/2:

The type of a parameter or the return type for a function definition shall not be a (possibly cv-qualified) class type that is incomplete or abstract within the function body unless the function is deleted ([dcl.fct.def.delete]).

[leni536]

So it actually has something to do with [dcl.fct.def.general]/2:

The error is present even if the constructor is not defined and A<void> is implicitly instantiated.

https://godbolt.org/z/dMTsvE3xE

It does seem to be a bit overzealous "is this a nonsense copy constructor?" check in implementations and probably in the wording too.

A declaration of a constructor for a class X is ill-formed if its first parameter is of type cv X and either there are no other parameters or else all other parameters have default arguments. A member function template is never instantiated to produce such a constructor signature.

I think it is clear that for the instantiated declaration is ill-formed under this wording. Maybe it could be relaxed for cases where the declaration is constrained away.

[ranaanoop]

@leni536 Even if we replace A<void> a; with A<int> a;, your program is still rejected which is what I think is the problem i.e the program is rejected irrespective of what T is. demo. It'd be less surprising and more in intent of the user for the program to be accepted for A<int> a;.

@cpplearner If completeness was the problem then A(A, A<void>) should also be rejected but gcc and clang starts accepting the program if we replace A(A<void>) with A(A,A<void>). This tells me that the issue isn't related to completeness.