Thats a pretty interesting article, thanks for pointing it out!

Only one page here, just needed to scroll a bit.

Is the font only small in my webbrowser? My eyes hurt. When I see such pages.

Aside from lambdas, rvalue references are probably the feature I am most excited about. For something so simple, it provides so much elegance for the very crucial features of move semantics and perfect forwarding.

Why don't they name it C++&&<<=*?

There was a similar thread where someone argued that even if you need to be explicit about it, it just makes it too easy for junior programmers to destroy stuff senior programmers want to keep using. I suppose the argument goes that those juniors won't bother to read / understand the linked article (or similar) but know that rvalue references and std::move are good for performance...

Personally, I don't trust language abstractions as a means of protecting someone from his own ineptitude. If anything, I think it makes it harder to spot them and weed them out or at least give them proper guidance; and at any rate, an inept person will screw up regardless of how much the language tries to shield him from it. That is not the purpose of language abstractions.

But it vanishes mysteriously only from temporaries as they go out of scope?

Ok, perhaps they should have followed their example of reinterpret_cast<T> (it's so ugly and long to keep people from using it), and named std::move std::move_it_so_I_might_never_see_my_data_again instead.

Which will just trade one kind of potential errors for another? For one thing, you can't return pointers to locals (optimizing returning by value seems to be one of the points of move semantics - doesn't it transparently move the return value out of the function, as long as a move constructor/assignment exists?). So there will be lots more of dynamic allocation?

I think rvalue references are a great idea. I'm only half way through the part 2 post now and I still have to go back and read part 1... I'm excited to see what other features to expect and what they'll look like (I may have already read about them, but I don't recall).

I made a wrapper for <algorithms> and found that some functions return an iterator or a const_iterator depending on the constness of the range. To avoid writing the same functions twice I came up with this:

Now, with auto there's no trickery needed:

template <class Range, class Type>
auto find(Range& range, const Type& value) -> decltype(range.begin());

//or ... -> decltype(std::find(range.begin(), range.end(), value))

rvalue references seem to require lots of overloads to use it actively: as I understand you can only take advantage of move semantics (std::move) safely when a) the functions leaves everything in a good state (e.g swap), b) std::move is used on a rvalue reference parameter if there is an overload that takes that parameter by const lvalue reference (so that the moving version is only used with the temporaries).

Temporaries may be passed to functions that keep pointers to them.

Which error are you talking about? I don't mean returning a pointer to a local, I mean allocating something on the heap and returning a pointer to it. Move semantics would not be required if functions returned pointers to heap data - but then C++ would need garbage collection, which is something the C++ committee does not want.

I wonder why they did not use implicit sharing though. Swap for vectors with implicit sharing is a simple pointer swap, for example. Any data structure that has value semantics but it has heap data internally is best treated with implicit sharing.

Example, please. How do I take a pointer to a temporary and manage to pass it to a function (as a rvalue reference) at the same time? In addition, would you really take the address of a temporary?

I don't entirely understand. Do you suggest that implementing copy-on-write (?) for classes is simpler? Could you show an example of how you'd implement a swap for a vector (and do rvalue references have only to do with swapping)?

I have a feeling that a non-optional GC would just turn C++ into a completely different language (why not program in a GC language in the first place?) and optionally not using it would be out of the question if the standard way of doing things would be what you describe.