Syntax for universal references

Question

This is an rvalue reference:

void foo(int&& a);

It does not bind to lvalues:

int i = 42;
foo(i);   // error

This is a universal reference:

template<typename T>
void bar(T&& b);

It binds to rvalues and it also binds to lvalues:

bar(i);   // okay

This is an rvalue reference:

template<typename T>
struct X
{
    void baz(T&& c);
};

It does not bind to lvalues:

X<int> x;
x.baz(i);   // error

Why do universal references use the same syntax as rvalue references? Isn't that an unnecessary source of confusion? Did the committee ever consider alternative syntaxes like T&&&, T&*, T@ or T&42 (just kidding on that last one)? If so, what were the reasons for rejecting alternative syntaxes?

Answer 1

A universal reference such as T&& can deduce T to be an "object type", or a "reference type"

In your example it can deduce T as int when passed an rvalue, so the function parameter is int&&, or it can deduce T as int& when passed an lvalue, in which case the function parameter is int& (because the reference collapsing rules say std::add_rvalue_reference<int&>::type is just int&)

If T isn't deduced by the function call (as in your X::baz example) then it can't be deduced to int&, so the reference isn't a universal reference.

So IMHO there's really no need for new syntax, it fits nicely into template argument deduction and reference collapsing rules, with the small tweak that a template parameter can be deduced as a reference type (where in C++03 a function template parameter of type T or T& would always deduce T as an object type.)

These semantics and this syntax were proposed right from the beginning when rvalue references and a tweak to the argument deduction rules were proposed as the solution to the forwarding problem, see N1385. Using this syntax to provide perfect forwarding was proposed in parallel with proposing rvalue references for the purposes of move semantics: N1377 was in the same mailing as N1385. I don't think an alternative syntax was ever seriously proposed.

IMHO an alternative syntax would actually be more confusing anyway. If you had template<typename T> void bar(T&@) as the syntax for a universal reference, but the same semantics as we have today, then when calling bar(i) the template parameter T could be deduced as int& or int and the function parameter would be of type int& or int&& ... neither of which is "T&@" (whatever that type is.) So you'd have grammar in the language for a declarator T&@ which is not a type that can ever exist, because it actually always refers to some other type, either int& or int&&.

At least with the syntax we've got the type T&& is a real type, and the reference collapsing rules are not specific to function templates using universal references, they're completely consistent with the rest of the type system outside of templates:

struct A {} a;
typedef A& T;
T&& ref = a;    // T&& == A&

Or equivalently:

struct A {} a;
typedef A& T;
std::add_rvalue_reference<T>::type ref = a;    // type == A&

When T is an lvalue reference type, T&& is too. I don't think a new syntax is needed, the rules really aren't that complicated or confusing.

Answer 2

Why do universal references use the same syntax as rvalue references? Isn't that an unnecessary source of confusion? Did the committee ever consider alternative syntaxes...

Yes, it is confusing, IMO (I'll disagree with @JonathanWakely here). I remember that during an informal discussion (lunch, I think) about the early design of the overall feature we did discuss different notations (Howard Hinnant and Dave Abrahams were there bringing their idea and the EDG guys were giving feedback on how it could be fit in the core language; this predates N1377). I think I remember &? and &|&& were considered, but all this was verbal; I'm not aware of meeting notes having been taken (but I believe this is also when John suggested the use of && for rvalue references). Those were the early stages of the design, however, and there were plenty of fundamental semantic issues to consider at the time. (E.g., during that same lunch discussion we also raised the possibility of not having two kinds of references, but instead having two kinds of reference parameters.)

A more recent aspect of the confusion this causes is found in the C++17 feature of "class template argument deduction" (P0099R3). There a function template signature is formed by transforming the signature of constructors and constructor templates. For something like:

template<typename T> struct S {
  S(T&&);
};

a function template signature

template<typename T> auto S(T&&)->S<T>;

is formed to use for the deduction of a declaration like

int i = 42;
S s = i;  // Deduce S<int> or S<int&>?

Deducing T = int& here would be counter-intuitive. So we're having to add a "special deduction rule to disable the special deduction rule" in this circumstance :-(

Answer 3

As a developer with only a few years of C++ experience, I must agree that universal references are confusing. It seems to me that this stuff is completely impossible to understand, let alone actively use without reading Scott Meyers and/or watching the relevant talks on YouTube.

It is not just that && can be either an r-value reference or a "universal reference", it is the way templates are used to distinguish the types of reference. Imagine you are a normal engineer working in software development. You read something like:

template <typename T>
void foo (T&& whatever) {...}

and then the function body of foo tells you that the input parameter must be a very specific class type that has been defined in an in-house library. Wonderful, you think, the template is obsolete in the current software version, probably its a leftover from previous developments, so let's get rid of it.

Good luck with the compiler errors…

Nobody who hasn't learned this explicitly would assume that you'd implement foo as a function template here just to employ template deduction rules and reference collapsing rules which happen to coincide so that you end up with what is called "perfect forwarding". It really looks more like a dirty hack than anything else. I think creating a syntax for universal references would have made things simpler, and a developer who used to work on an older code base would at least know that there is something that has to be googled here. Just my two cents.