|
|
|
|
|
|
by saghm
1261 days ago
|
|
|
I'd be pretty surprised if the C++ move semantics were considered more intuitive by someone not familiar with either and then learning both for the same time. Rust's semantics do depend on the type in that anything that implements Copy will be implicitly copied rather than moved, but I'm sure I understand why that's unintuitive. I'm also not sure what you mean by Rust having it's own move operator; the only thing I can think of is the `move` keyword used for indicating that closures should capture by move rather than by reference, but it's not used outside of closures as far as I'm aware, so I suspect that the confusion here is more due to expecting things to behave like C++ rather than the Rust semantics being "unintuitive" in a vacuum. At a high level, I think the most unintuitive part of moving in C++ compared to Rust is that it can silently degrade into a copy without anything indicating it. In Rust, trying to use a value after it's been moved will give you a compiler error, at which point you can reconsider whether you do in fact want to explicitly copy or if you made a mistake or need to refactor. In C++, the only way I'm aware of to verify whether a value is actually moved or not is to use a debugger. The benefit for requiring explicit copies is similar to having bindings be immutable by default and requiring an explicit `mut` annotation; if you start out enforcing the constraint that things should be moved or immutable, fixing it later if you find out it won't work that way only requires adding `.clone()` or `mut` in one place. On the other hand, if you start out with implicit copies or mutability by default and then want to change it later, it can be a lot more work to refactor the places where the variable is used to not violate this, and it may not even be possible in some cases. |
|
|
Not as simple as if there was a proper borrow checker but its sort of possible:
https://awesomekling.github.io/Catching-use-after-move-bugs-...