This is a late answer and so VS2017 have changed since your comment.
With the latest VS2017 update though:

std::is_reference{} 

seem indeed not to be working; however, using:

std::is_reference::value
// or even
std::is_reference_v

works.

You’re right Puneet and Denis. I was mistaken by thinking that U& and U const& couldn’t be two overloads. I amended the sentence in the post following your remarks. Thanks a lot guys for being so accurate in your reading, and for making me learn these things!

Hello everyone.

Puneet is right. This statement is not true.

“T const&” becomes “U& const&” which collapses into “U&”, not
“U const&”. Since “T&&” becomes “U& &&” which collapses into “U&” too, there is an ambiguity.

From N4659 (2017-03-21) §11.3.2:
If a typedef-name (10.1.3, 17.1) or a decltype-specifier (10.1.7.2) denotes a type TR that is a reference to a type T, an attempt to create the type “lvalue reference to cv TR” creates the type “lvalue reference to T”, while an attempt to create the type “rvalue reference to cv TR” creates the type TR. [ Note: This rule is known as reference collapsing. —end note ]

The code below compiles with GCC:
#include
template
void test(RefToInteger const& param) {
param = 0;
}
int main()
{
int i = 5;
test(i); // “RefToInteger const&” becomes “int&”.
std::cout << i; // prints 0
return 0;
}

Thanks Peter for bringing up this issue. I’ll get back to you as soon as I have an answer for this.

Well, in this case because of refernce collpasing rules, const is also being dropped, that is why we are getting the ambiguity. Sorry, I found it a little confusing

yes, still keep T as a data member, and only update move constructor as :
explicit Namedtype(decay_t&& value) ;

I think you would have a “std::decay::type value_;”…