3 ms·
> compiler will reject programs that use the moved-from value. Yes, this is something the C++ 'language' is not going to specify other than claiming that it is
by fooker 1y ago
> compiler will reject programs that use the moved-from value.
Yes, this is something the C++ 'language' is not going to specify other than claiming that it is undefined behavior.
Doesn't prevent compilers from doing it though, clang will happily do this for you right now in most cases.
https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-analysis-in-clang/86291 https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-a...
- ninkendo 1y agoBut it's not undefined behavior. That's the key. It's "unspecified behavior", meaning that according to the standard, it's allowed. A program that reuses a moved-from value is considered valid and well-formed by the standard. It merely delegates how to make this work to the individual implementation (a string becomes an empty string, a vector becomes an empty vector, etc.) The RFC you posted has nothing to do with move semantics, it's about references outliving what they point to (ie. use-after-free, etc) and similar to Rust's borrow checker. But here's the thing: move semantics and the borrow checker have nothing to do with each other! The borrow checker ensures that borrowed data (ie. &Foo, equivalent to C++'s references) is sound, it's not the part that enforces move semantics. That happens earlier in the compilation, the compiler enforces moves well before the borrow checker phase.