Note that in C++ every object that can be moved from has to have a "valid, but unspecified" moved-from state, so C++ doesn't need drop flags to keep track of validity because the drop flag is part of the type. It's also not necessarily true that moving out of something twice is a no-op; you still have to construct an "empty" object to put in the temporary, because it will be dropped. Chances are good this is cheap but not free.
Rust doesn't work like that. Moved-from objects are like destroyed objects: invalid and inaccessible. A major advantage to this is that all types can have move semantics, not just ones that have some kind of valid "empty" state. A side effect is that the compiler sometimes has to emit drop flags to know whether a thing has been moved-from or not (but note that drop flags are part of the variable, not part of the type like in C++ -- you can't move a value out of the middle of a
Vec and leave an "empty" object in its place).
It's because of this different model that drop flags are kind of implicit and hidden from the programmer. Drop flags aren't really an explicit feature of variables; they're just a consequence of the scope rules, and they are frequently optimized out entirely. There's no syntax that would allow you to check drop flags because that would break the abstraction. Of course, if you really need to, you can
mem::replace(&mut foo, Default::default()), which is the spiritual equivalent to "moving out of" a C++ variable, and works for anything that is
Default. And if your variable isn't
Default, you can wrap it in
Option. But that's really not something that comes up that often. Like I said in my first post in this thread, the usual way to end a value's life is to make it go out of scope. That is how you use drop flags. I can't think of a scenario where being able to check drop flags would help, that can't be trivially rewritten to use scopes -- can you?