Rationale for move/copy/borrow syntax

[grothesque]

@CAD97

@steffahn

Now, what do we do with value expressions?

Taking this train of thought to its logical conclusion, you end up with something similar to C++ rvalue reference rules. Wherever you have a temporary value known not to be used again (or use std::move to say you're not going to use an lvalue again), the rvalue reference (move) overload applies.

Applied a Rust-ish world like described by the OP, an rvalue would move by default without annotation but if that doesn't work also allow pass-by-ref. You'd essentially get C++'s move rules except with destructive moves, meaning the language handles preventing access to and suppressing the destructors of moved-from values rather than leaving it to be handled by user code.

Thanks, I think that this goes very much into the direction of expressing my gut feelings more clearly.

In which ways would such a language be better or worse compared to Rust? It could still be as safe as Rust I imagine (borrow checker). Would it be less explicit in a way that affects performance?

Just using modern C++ instead is not really a good option. The fundamental problem (besides its baroque complexity) is that it is very easy to write a short program that is very simple (no heap allocations, no pointers), but still segfaults because of a single & too much. And the compiler is unable to warn, even with maximum warnings enabled!