4 ms·

At this time, what can Rust accomplish with the borrow checker that C++ can't accomplish with move semantics?

• bjz_ 11y ago
  Rust's moves are implicit, making it easier to write code that doesn't copy heap allocated memory, and you can't get 'use after moves' like in C++ - the type system will pick that up.
  • rjeli 11y ago
    Oh, having only read about and not used recent C++ practices, I assumed use-after-move would be caught at compile time. Looking around a bit, it seems there's not even a warning for this; is there a reason? It seems like it would be very useful.
    • Animats 11y ago
      Move is a template level concept, not a language concept. The compiler has no idea that something was moved, rather than assigned. Some implementations null out the "moved from" reference, so that a use after move will dereference null and crash the program. I've referred to the attempts to fix C++ ownership semantics with templates as "wallpapering over the mold".
    • girvo 11y ago
      > is there a reason Yeah, basically that it's quite difficult to implement especially with C++'s baggage and undefined behaviour, from what I remember
    • catnaroek 11y ago
      In C++, "moving" and "copying" are a matter of class design. While you are expected to use move (resp. copy) constructors and assignments to, well, move (resp. copy); the language doesn't rule out using them for other purposes. In Rust, assignment and argument passing always move, "moving" always does the right thing (make a shallow copy and invalidate the original object), and you can't override this behavior. Furthermore, Rust splits what C++ calls "copying" into two concepts: shallow copying (which is the same as moving, except the original object isn't invalidated, and the type checker guarantees you can only do it when it makes sense) and deep cloning (which may be expensive and needs to be explicitly requested by the programmer). This is why Rust can track which objects are no longer usable.
• Too 11y ago
  In c++ if you pass something as reference there is nothing preventing the receiving function from keeping a pointer to that reference even after returning. Right now the only way to enforce this is by convention: 1. move/unique/shared_ptr=receiver allowed to keep pointer, 2. raw ptr=totally banned, 3. reference=caller must outlive callee and called function is not allowed to keep pointer after returning. The last scenario here is not enforcable by the compiler.
• sebastic 11y ago
  Compiler will not warn this: MovableObject a, b, c; b = std::move(a); c = std::move(a); `c` may contain garbage. BTW the "move trait" (as its called in rust) is a related but orthogonal concept to its borrow checker.
  • catnaroek 11y ago
    In Rust, moving isn't a trait. It's the default, non-overridable behavior of assignment and argument passing. And everything is movable.
• loqi 11y ago
  Rust disallows mutation of multiply-referenced data, which prevents things like iterator invalidation and data races.