5 ms·
They are more limited than C++ moves for sure, whether that is a good or a bad thing I am not so sure of! I am curious if there are any examples of things you
by chlorion 5y ago
They are more limited than C++ moves for sure, whether that is a good or a bad thing I am not so sure of!
I am curious if there are any examples of things you wanted to do but couldn't with Rusts move semantics.
After using both C++ and Rust I personally feel that the way Rust handles moves makes a lot more sense and ends up being much more ergonomic. In C++ moves feel messy and complex due to them being added on rather than having the language built around them from the start. It's also not ideal that C++ moves must leave values hanging around in an unspecified state rather than destroying them immediately, even if there are a few cases where that is useful, most of the time it's not.
Rust also doesn't have any of the crazy `&&T` rvalue reference stuff or require explicitly defining move constructors since everything is movable and all moves are bitwise copies.
- steveklabnik 5y agoThe classic thing that's tough to do is self-referential structures; since you have no hook into moves, you can't fix-up the references. It also has quite a few pros, and many people think it's better the way it is. Since moves are memcopies, they can never fail, meaning there's no opportunities for panics, which means it's much easier to optimize. They aren't arbitrarily expensive; you always know what the cost is. As you mentioned, there's no need for a "moved-from" state, which can save space and/or program logic.
- ncmncm 5y agoIt is correct to say that allowing move constructors to fail was a grave design mistake.