What is the "rvalue reference for *this" proposal?

Question

Came across a proposal called "rvalue reference for *this" in clang's C++11 status page.

I've read quite a bit about rvalue references and understood them, but I don't think I know about this. I also couldn't find much resources on the web using the terms.

There's a link to the proposal paper on the page: N2439 (Extending move semantics to *this), but I'm also not getting much examples from there.

What is this feature about?

Associative

Answer 1

First, "ref-qualifiers for *this" is a just a "marketing statement". The type of *this never changes, see the bottom of this post. It's way easier to understand it with this wording though.

Next, the following code chooses the function to be called based on the ref-qualifier of the "implicit object parameter" of the function^†:

// t.cpp
#include <iostream>

struct test{
  void f() &{ std::cout << "lvalue object\n"; }
  void f() &&{ std::cout << "rvalue object\n"; }
};

int main(){
  test t;
  t.f(); // lvalue
  test().f(); // rvalue
}

Output:

$ clang++ -std=c++0x -stdlib=libc++ -Wall -pedantic t.cpp
$ ./a.out
lvalue object
rvalue object

The whole thing is done to allow you to take advantage of the fact when the object the function is called on is an rvalue (unnamed temporary, for example). Take the following code as a further example:

struct test2{
  std::unique_ptr<int[]> heavy_resource;

  test2()
    : heavy_resource(new int[500]) {}

  operator std::unique_ptr<int[]>() const&{
    // lvalue object, deep copy
    std::unique_ptr<int[]> p(new int[500]);
    for(int i=0; i < 500; ++i)
      p[i] = heavy_resource[i];

    return p;
  }

  operator std::unique_ptr<int[]>() &&{
    // rvalue object
    // we are garbage anyways, just move resource
    return std::move(heavy_resource);
  }
};

This may be a bit contrived, but you should get the idea.

Note that you can combine the cv-qualifiers (const and volatile) and ref-qualifiers (& and &&).

---

^{Note: Many standard quotes and overload resolution explanation after here!}

† To understand how this works, and why @Nicol Bolas' answer is at least partly wrong, we have to dig in the C++ standard for a bit (the part explaining why @Nicol's answer is wrong is at the bottom, if you're only interested in that).

Which function is going to be called is determined by a process called overload resolution. This process is fairly complicated, so we'll only touch the bit that is important to us.

First, it's important to see how overload resolution for member functions works:

§13.3.1 [over.match.funcs]

p2 The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. [...]

p3 Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on.

Why do we even need to compare member and non-member functions? Operator overloading, that's why. Consider this:

struct foo{
  foo& operator<<(void*); // implementation unimportant
};

foo& operator<<(foo&, char const*); // implementation unimportant

You'd certainly want the following to call the free function, don't you?

char const* s = "free foo!\n";
foo f;
f << s;

That's why member and non-member functions are included in the so-called overload-set. To make the resolution less complicated, the bold part of the standard quote exists. Additionally, this is the important bit for us (same clause):

p4 For non-static member functions, the type of the implicit object parameter is

• “lvalue reference to cv X” for functions declared without a ref-qualifier or with the & ref-qualifier

• “rvalue reference to cv X” for functions declared with the && ref-qualifier

where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [...]

p5 During overload resolution [...] [t]he implicit object parameter [...] retains its identity since conversions on the corresponding argument shall obey these additional rules:

• no temporary object can be introduced to hold the argument for the implicit object parameter; and

• no user-defined conversions can be applied to achieve a type match with it

[...]

(The last bit just means that you can't cheat overload resolution based on implicit conversions of the object a member function (or operator) is called on.)

Let's take the first example at the top of this post. After the aforementioned transformation, the overload-set looks something like this:

void f1(test&); // will only match lvalues, linked to 'void test::f() &'
void f2(test&&); // will only match rvalues, linked to 'void test::f() &&'

Then the argument list, containing an implied object argument, is matched against the parameter-list of every function contained in the overload-set. In our case, the argument list will only contain that object argument. Let's see how that looks like:

// first call to 'f' in 'main'
test t;
f1(t); // 't' (lvalue) can match 'test&' (lvalue reference)
       // kept in overload-set
f2(t); // 't' not an rvalue, can't match 'test&&' (rvalue reference)
       // taken out of overload-set

If, after all overloads in the set are tested, only one remains, the overload resolution succeeded and the function linked to that transformed overload is called. The same goes for the second call to 'f':

// second call to 'f' in 'main'
f1(test()); // 'test()' not an lvalue, can't match 'test&' (lvalue reference)
            // taken out of overload-set
f2(test()); // 'test()' (rvalue) can match 'test&&' (rvalue reference)
            // kept in overload-set

Note however that, had we not provided any ref-qualifier (and as such not overloaded the function), that f1 would match an rvalue (still §13.3.1):

p5 [...] For non-static member functions declared without a ref-qualifier, an additional rule applies:

• even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.

struct test{
  void f() { std::cout << "lvalue or rvalue object\n"; }
};

int main(){
  test t;
  t.f(); // OK
  test().f(); // OK too
}

---

Now, onto why @Nicol's answer is atleast partly wrong. He says:

Note that this declaration changes the type of *this.

That is wrong, *this is always an lvalue:

§5.3.1 [expr.unary.op] p1

The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points.

§9.3.2 [class.this] p1

In the body of a non-static (9.3) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. [...]

Saintly

I believe the paraneter types right after "after the transformation" section should be 'foo' instead of 'test'. – Associative

@ryaner: Good find, thank you. Though not the parameter but the class identifier of the functions is wrong. :) – Saintly

oops sorry I forgot about the toy class named test when I read that part and thought f is contained within foo thus my comment.. – Associative

Can this be done with constructors: MyType(int a, double b) &&? – Idler

@GermánDiago: No. What is the intent? – Saintly

@GermánDiago, I would like to be able to do mark constructors as const for types that are being built as const. It might allow us to store some data in a more efficient way, if we knew this particular object would never have to be modified. Not sure I can see a use for && and & constructors however. – Mediant

It would be cool if the type of *this could be T& or T&& depending on the ref qualifier in effect. You might worry that this would mean that this would be a pointer-to-reference, which is impossible. But I think we can avoid that by saying that, within ref-qualified methods, this is no longer a raw pointer. Instead, it would be a pointer-like type would would have suitable overloads and conversions defined. Maybe it's a bit late to introduce this change, perhaps it should have been introduced along with ref-qualified methods. – Mediant

"The type of *this never changes" You maybe should be a little clearer that it doesn't change based on r/l-value qualification. but it can change between const/non-const. – Tolerate

I wonder if there's a proposal to change the type of *this based on the ref-qualifier. Maybe it's too narrow use-case and most people are fine with using std::move(*this) instead. – Potentiate

Answer 2

There is an additional use case for the lvalue ref-qualifier form. C++98 has language that allows non-const member functions to be called for class instances that are rvalues. This leads to all kinds of weirdness that is against the very concept of rvalueness and deviates from how built-in types work:

struct S {
  S& operator ++(); 
  S* operator &(); 
};
S() = S();      // rvalue as a left-hand-side of assignment!
S& foo = ++S(); // oops, dangling reference
&S();           // taking address of rvalue...

Lvalue ref-qualifiers solve these problems:

struct S {
  S& operator ++() &;
  S* operator &() &;
  const S& operator =(const S&) &;
};

Now the operators work like those of the builtin types, accepting only lvalues.

Tepee

for me this line won't compile! how come yours compile! &S(); // taking address of rvalue... – Smilax

Answer 3

Let's say you have two functions on a class, both with the same name and signature. But one of them is declared const:

void SomeFunc() const;
void SomeFunc();

If a class instance is not const, overload resolution will preferentially select the non-const version. If the instance is const, the user can only call the const version. And the this pointer is a const pointer, so the instance cannot be changed.

What "r-value reference for this` does is allow you to add another alternative:

void RValueFunc() &&;

This allows you to have a function that can only be called if the user calls it through a proper r-value. So if this is in the type Object:

Object foo;
foo.RValueFunc(); //error: no `RValueFunc` version exists that takes `this` as l-value.
Object().RValueFunc(); //calls the non-const, && version.

This way, you can specialize behavior based on whether the object is being accessed via an r-value or not.

Note that you are not allowed to overload between the r-value reference versions and the non-reference versions. That is, if you have a member function name, all of its versions either use the l/r-value qualifiers on this, or none of them do. You can't do this:

void SomeFunc();
void SomeFunc() &&;

You must do this:

void SomeFunc() &;
void SomeFunc() &&;

Note that this declaration changes the type of *this. This means that the && versions all access members as r-value references. So it becomes possible to easily move from within the object. The example given in the first version of the proposal is (note: the following may not be correct with the final version of C++11; it's straight from the initial "r-value from this" proposal):

class X {
   std::vector<char> data_;
public:
   // ...
   std::vector<char> const & data() const & { return data_; }
   std::vector<char> && data() && { return data_; }
};

X f();

// ...
X x;
std::vector<char> a = x.data(); // copy
std::vector<char> b = f().data(); // move

Shirl

I think you need to std::move the second version, non? Also, why the rvalue reference return? – Saintly

@Xeo: Because that's what the example was in the proposal; I have no idea if it still works with the current version. And the reason for the r-value reference return is because the movement should be up to the person capturing it. It shouldn't happen yet, just in case he actually wants to store it in a && instead of a value. – Shirl

Right, I kinda thought of the reason for my second question. I wonder though, does an rvalue reference to the member of a temporary prolong the lifetime of that temporary, or the member thereof? I could swear I saw a question about that on SO some time ago... – Saintly

-1. it doesnt change the value category of implicit class member access. – Shrunken

I just noticed that you wrote "If a class instance is not const, the user can only call the non-const version of the function.", that is wrong. const functions can still be called on non-const lvalues. – Saintly

@Xeo: It's not entirely true. Overload resolution will always pick the non-const version if it exists. You would need to do a cast to get the const version. I've updated the post to clarify. – Shirl

@Nicol: You still got wrong that ref-qualifiers do not change the type of *this. See the bottom of my answer. – Saintly

I thought I might explain, after all I created this feature for C++11 ;) Xeo is right in insisting that it does not change the type of *this, however I can understand where the confusion comes from. This is because ref-qualifier changes the type of implicit (or "hidden") function parameter to which "this" (quotes put on purpose here!) object is bound during overload resolution and function call. So, no change of *this since this is fixed as Xeo explains. Instead change of "hiddden" parameter to make it lvalue- or rvalue-reference, just like const function qualifier makes it const etc.. – Suppurate

@bronekk: Though in the case of const, decltype(this) changes (or not, since its cv-qualification is only determined through the cv-qualifiers, after all). – Saintly

In the last example, f().data() does a move because the selected data() function returns an xvalue, not because the type of *this differs. If you change it so that both versions return an lvalue reference, it will no longer be a move. – Saponin

@M.M: My point is that the reason it is reasonable for the && version to return an rvalue reference is because it uses the && qualifier for this. That overload will only be called if the expression it is invoked on is an rvalue, so you have permission to move from whatever internal object it is referencing. – Shirl