58 ms·

Moves don't require any runtime checks in Rust to my knowledge. Moves do involve some compile time analysis to make sure you aren't accessing a value that has b

Moves don't require any runtime checks in Rust to my knowledge. Moves do involve some compile time analysis to make sure you aren't accessing a value that has been moved, maybe that is what you are thinking of? In Rust, moves are always a simple memcpy from one place to another, that's it! With non `Copy` types this destroys the original value which is why the compiler makes sure you don't access it after it's moved. There is also `Clone` which is generally a deep copy of everything, but this also doesn't involve any runtime checks as long as you aren't using reference counted pointers or something. There are bounds checks when indexing into vectors and whatnot though, but non checked methods are available.

ncmncm 5y ago
In other words, moves in Rust are very limited and limiting.
- 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 ago
    The 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 ago
      It is correct to say that allowing move constructors to fail was a grave design mistake.

ncmncm 5y ago

In other words, moves in Rust are very limited and limiting.

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 ago
  The 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 ago
    It is correct to say that allowing move constructors to fail was a grave design mistake.