I understand that, given an expression initializing a forwarding/universal reference,lvalues are deduced to be of type T& and rvalues of type T (and not T&&).
Thus,to allow only rvalues, one need to write
template<class T, enable_if<not_<is_lvalue_reference<T> >,OtherConds... > = yes>
void foo(T&& x) {}
and not,
template<class T, enable_if<is_rvalue_reference<T>,OtherConds... > = yes>
void foo(T&& x) {}
My question is , why for forwarding references, rvalues are deduced to be of type T and not T&& ? I guess, if they are deduced as T&& then also same referencing collapsing rule works as T&& && is same as T&&.
Because at the time, deducing rvalue A arguments as A&& instead of A was seen as an unnecessary complication and departure from the normal rules of deduction:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
We really didn't even know if we could get one exception of the deduction rules (for the lvalue A case), and it never even occurred to us that we would dare ask for two exceptions. To do so, the benefit would have had to have been: It makes what is impossible, possible.
After all, without the single special deduction rule for the lvalue case, perfect forwarding is impossible, as N1385 so aptly demonstrated.
Even with today's hindsight, adding another special deduction rule so that the client can avoid having to negate a template constraint, does not seem like a very high benefit/cost ratio. Especially compared to the benefit/cost ratio we were shooting for in 2002.
来源：https://stackoverflow.com/questions/16373881/why-forwarding-reference-does-not-deduce-to-rvalue-reference-in-case-of-rvalue