But rvalue references and auto_ptr are still a completely different thing? (The former is even a way to fix the latter: provide a really simple smart pointer that you can store safely in standard containers etc.)

The compiler will implicitly move only in places where you can't miss the original (those rules have been in place for a long time, e.g where copy constructor calls can be elided), and in addition rvalue references provide a sure way to determine cases where it is always safe to move explicitly. In addition there are a few specific cases where moving is OK due to the nature of the algorithm (swap, when resizing vector etc).

#include <vector>
#include <memory>

using namespace std;

int main()
{
    vector<unique_ptr<int>> v;
    unique_ptr<int> p (new int);
    v.push_back(p);  //compiler error: unique_ptr is non-copyable
    v.push_back(unique_ptr<int>(new int)); //OK, and you can't miss this unique_ptr
}

And you have mentioned this a couple of times as well. Provide a real example of what foo would have to look like without a dumb use of std::move and then keeping using the same variable.

Yes, given a large and messy codebase written by people that come and go, I can imagine that any line can contain any arbitrary hidden bug. Misuse of std::move seems to be on the benign end of things that could go wrong.

What I'm saying that rvalue references seem to protect you quite nicely from honest human errors, but not from incompetence, and are therefore much easier and safer to use than many other existing features.

But when an object has been moved from, it is not deleted memory in the same sense as what you get when you type delete p;. That object has to be in a good enough state, so at least its destructor can still run (e.g it contains NULL pointers, or I suppose it might have swapped the pointers).

Unlike misusing delete, where the language itself cannot check that you follow a sensible ownership policy, with rvalue references you have a good idea where std::move cannot hurt. The only thing to keep in mind is not to keep using the moved-from object, unless you put it in a good state again (mostly you'd move from things that are going out of scope anyway).

#include <cstdio>
#include <memory>

int main()
{
    std::unique_ptr<int> a(new int(10));
    std::unique_ptr<int> b(std::move(a));
    a.reset(new int(20));  //this should be OK
    printf("%d %d\n", *a, *b);
}

Yea, welcome to Java/perl/python/ocaml/scheme/ruby/javascript/anything invented in the past 20 years.

Is there that much to fit into the head? Wouldn't it be enough to look at current function to know whether a move is good or not? (Completely unlike delete where either you have a very clear ownership policy or you are completely lost.)

void foo(X&& x)
{
    X other = std::move(x);
    x.bar(); //don't do this (using moved-from object)
}

void foobar(X& x)
{
    foo(std::move(x)); //don't do this either (moving from lvalue reference without restoring x)
}

Perl has pointers. It calls them references, but its the same thing. And if you feel really dirty, you can actually use real addresses, and turn it into a perl object.

my $var = "SCALAR(0xdeadbeef)"; $$var = "foo"; # BAD!

edit: I realize thats not actually how you do it, but its something like that, and something I've only done once in the past 10+ years I've been codeing in perl, so I don't remember how its done.

It just does not scale well. If, in your example, the move call and the x.bar() call was a few pages apart, for example, then you might easily miss it.