rvalue references

[Diggory]

> I don't see myself ever getting on board with this auto-ref 
> idea. I just
> think it's crazy. It makes no sense to me, they are completely 
> unrelated
> concepts. It will only lead to confusion.
>
> I'm back at scope-ref. Kenji is right as far as I'm concerned. 
> Not to
> mention, he actually did the work.
> It makes perfect sense, and I can't see any reason why auto-ref 
> should be
> used instead of something that actually makes intuitive sense, 
> and people
> will eventually want to use anyway...

I'm against "scope ref" as the one thing "scope" means is that 
the parameter cannot be returned, and preventing rvalue 
references being returned breaks the one thing they are useful 
for.

The primary use of rvalue references in C++ is so that these 
three cases work:
vector<T> vec;
T t;
vec.push_back(T()) // Move semantics (temporary is destroyed in 
the process)
vec.push_back(t) // Copy semantics ('t' is unmodified)
vec.push_back(move(t)) // Move semantics ('t' is destroyed in the 
process)

This allows best efficiency (move is at least as fast as copy, so 
when the original is no longer needed a move should be performed)

The way it works is that push_back() has two overloads:
push_back(T&& v) {
     // Move 'v' into the vector, afterwards 'v' will have had its 
guts ripped out so to speak...
}
push_back(const T& v) {
     // Copy 'v' into the vector, 'v' is unmodified
}

- r-values such as 'T()' will default to the first overload.
- l-values such as 't' will default to the second overload.
- 'move(t)' returns an r-value causing the first overload to be 
called.

As you can see, using "scope ref" will break this third case 
because 'move()' won't be able to return an r-value, and if only 
the first two cases are going to be possible, this can be done 
without any special notion of r-value references anyway.

I'm starting to think there does need to be new syntax if all 
three of the above cases are to be covered - it would work just 
making "ref" accept rvalues but then "move" would be the default 
for lvalues, and that would be confusing - but I don't think 
using "scope" solves any problems, as the semantics required for 
rvalues are orthogonal to what "scope" actually means.

As good as it is to avoid adding new keywords, I think this might 
be a case where it's warranted...