Template Constructor Taking Precedence Over Normal Copy and Move Constructor?

Question

The output of the following program...

#include <iostream>

using namespace std;

struct X
{
    X(const X&)              { cout << "copy" << endl; }
    X(X&&)                   { cout << "move" << endl; }

    template<class T> X(T&&) { cout << "tmpl" << endl; }
};

int main()
{
    X x1 = 42;
    X x2(x1);
}

is

tmpl
tmpl

The desired output is:

tmpl
copy

Why doesn't the concrete copy constructor take precedence over the template constructor?

Is there anyway to fix it so that the copy and move constructor overloads will take precedence over the template constructor?

Answer 1

Well, it is because of reference-collapsing.

At the overload resolution stage, when the function template is instantiated, T is deduded to be X&, so T&& (which is X& &&) becomes X& due to reference-collapsing, and the instantiated function from the function template becomes exact match and the copy-constructor requires a conversion from X& to const X& (which is why it is not selected being inferior match).

However, if you remove the const from the copy-constructor, the copy-constructor will be preferred. Try this:

X(/*const*/ X&) { cout << "copy" << endl; }

Output as expected.

Or alternatively, if you make the parameter in the function template as const T& then copy-constructor will be called (even if it remains same!), because reference-collapsing will not come into picture now:

template<class T> X(const T &) { cout << "tmpl" << endl; }

Output is expected, again.

Answer 2

If you don't want to add another constructor (as other answers suggested), you can use SFINAE to constrain the call, by replacing your template constructor by this:

template<class T
    , typename std::enable_if<not std::is_same<X, typename std::decay<T>::type>::value, int>::type = 0 
> X(T&&) { cout << "tmpl " << endl; }

Which just involves adding a dummy default template argument (a known technique: Link). No extra headers are necessary.

You will get the desired output.

I got this answer from a related problem: Link. All this looks rather inelegant, but seems to be the only way out for now. I still would like to see a more elegant solution.