I wanted to figure out an example to explain RValue References and was starting an example with the code (similar to your vector factory):

struct BigThing {
  explicit BigThing(int i);
  BigThing(BigThing&&);  //move
  BigThing(BigThing&) = deleted;  //no copy
};

BigThing create_big_thing(int i) {
  BigThing ver1(i/2); // prevent construction
  BigThing ver2(i*3+1); //... in place of 'bt'
  return i%2==0 ? ver1 : ver2;
}
int main() {
  BigThing bt = create_big_thing(66);
}

I was a bit surprised that the compiler accepted that, but pleased. Move is better then Copy. I looked up [class.copy] and found in paragraph 20 the explanation of “overload resolution with an rvalue first”. Great — so it’s safe to delete Copy but implement Move to force high-perf code only.

But then I remembered your example and Howards explanation:

  Matrix operator+(Matrix&& temp, Matrix&& y)
  { temp += y; return std::move(temp); }

Here the “move” is necessary because y must be treated as an lvalue inside the function. Ok, I understood that. But whats the difference? Ah, paragraph 19: “[only] when the expression is the name of an automatic object”. That fits, y is not an automatic object.

Ok, complicated, but I think I got it. I just want to make sure here, I don’t want to use examples and doing the explanations wrong.

Did I get that right?

I also agree that it’s too bad that the compiler won’t put move(a) around the last use of a for me.

Not breaking old code is a nice ideal, but in my code I use similar to:

string const& b = "1"+string("2");

And apparently that will no longer work, so it’s not like old code is actually sacred.

To avoid move problems, we can be less restrictive than requiring inheritance only of abstract classes in OO hierarchies. Scott Meyers’ advice (Effective C++) that bases not have public copy operations is sufficient if it’s extended to move operations (including swap).

Another case to consider is when public inheritance is used to compose value types (not for polymorphism). Here slicing is possible, and perhaps occasionally desirable. Move operations seem to work naturally here too. ‘Move slicing’ might steal one resource but leave another to be cleaned up by the original object.

I think move is fundamentally more complicated because it is asymmetric.

If it would just be about efficiency and resilience, I would go for resilience (because a simple check for self-assignment won’t loose too much efficiency anyway). What I don’t like about the resilience option is that it might provoke even more non-trivial boilerplate code in my classes, if I’m unwilling to give up even more efficiency (by implementing move assignment with a call to the move constructor followed by a call to swap).

The other part of the problem is to formulate the decision in precise words. And it would be nice if even the non-native speaking reader…

But one final honest word: Move support will soon be widely available, the currently agreed upon interpretation of moving is quite different from ‘“std::move(a)” can be treated like a true temporary object’, so going with the resilient option and allow self-move-assignment would at least be consequent.

I don’t really understand anything you’re saying after this part (especially not your use of the word “twisted”), but the following gives me the sense you think the committee is being somehow inconsistent in supporting automatic move generation.

I’m not a native speaker, so I don’t know about the connotations of “twisted”. I used it with the following meaning in mind:

“twist” = “trick”

“twisted” = “not completely trivial”

The committee is consistent in supporting automatic move generation, because the copy constructor and assignment operator also get generated automatically. And it will help indeed for the problems that it tries to address.

I’m just a bit unhappy that moving turns into something significantly more complicated than swapping. And I have the impression that moving will inherit some of the problems swapping has:

(a) “swap” should be relatively cheap and don’t throw, otherwise it will be much less useful.

(b) A reasonable swap can’t be added to an existing class without modifying the source code of the class definition.

(c) calling “swap” with a pointer to a derived object is a really bad idea (worse than slicing), but it is impossible to forbid it.

Problems (a) is already actively being discussed for moving, and the automatic move generation tries to address (b). With respect to problem (c), someone once told me that it’s a good idea to only inherit from abstract classes. So as long as the abstract classes take care to declare the swap member function as protected, everything is fine. I don’t know whether the automatically generated move member functions will take care of this detail, or whether such details are important after all.

Sounds like that somebody might be you

I don’t think that this position is any more wrong or right than the opposite position

Agreed

I think the advantages of clear responsibilities are more important than some lost optimization opportunities.

That’s a very good point. Of course, saying that doesn’t help us choose one answer or the other. So we’re still left with efficiency and resilience as the two useful criteria.

I don’t really understand anything you’re saying after this part (especially not your use of the word “twisted”), but the following gives me the sense you think the committee is being somehow inconsistent in supporting automatic move generation.

Adding support for automatic generation of swap member functions to the c++ language was always a no-go, but now that the move member functions get so twisted, adding automatic generation for them to the c++ language is suddenly welcomed as a good idea.

My initial point was that somebody should defend the strict position that “a=std::move(a)” is not legal for a general “a”. I don’t think that this position is any more wrong or right than the opposite position that “a=std::move(a)” is legal for a general “a”.

From my point of view, it is a question of responsibility assignment. Does the caller has to ensure that “std::move(a)” can be treated like a true temporary object? Or does the called function has to ensure that nothing goes wrong? I think the advantages of clear responsibilities are more important than some lost optimization opportunities.

You may think that the unfixed swap example will always work in practice, but what about a class that actually asserts on self-move-assignment, even if the moved from object is empty? Sure this would be easy to fix by excluding the empty case from the assertion, but the question would remain, whether it is the calling function that is buggy or the called function. Is the called function allowed to assert at all, even for a self-move-assignment from a non-empty object? The caller might use an old std algorithm with a move_iterator and don’t care about the behavior in case of self-move-assignment, as long as the program doesn’t crash (or stops on an assert).

The interesting thing about this is that it’s not some boost-library that has to write the move member functions, but me as the individual programmer. Adding support for automatic generation of swap member functions to the c++ language was always a no-go, but now that the move member functions get so twisted, adding automatic generation for them to the c++ language is suddenly welcomed as a good idea. The funny thing is that automatically generated swap member functions would probably be much less error prone than automatically generated move member functions.

If that’s what you’re saying, I guess I don’t see how it relates to your earlier point. Or maybe I didn’t get your earlier point.

Of course you can invent twists to get around this simple logic conclusion. I reread

http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1204

And indeed, it uses a twist to get around my simple logic conclusion by writing: “Each of the following statements applies to all arguments to functions defined in the C++ standard library, UNLESS EXPLICITLY STATED OTHERWISE.”