3 ms·

Right, which is great, don't get me wrong. If you're going to have that behavior, having the compiler enforce it is good. I just think it's a bit amusing, peop

Right, which is great, don't get me wrong. If you're going to have that behavior, having the compiler enforce it is good. I just think it's a bit amusing, people complain about this sort of thing in C++ all the time. I can imagine if Rust takes over people will complain how you have no idea what u = v is doing unless you know what u and v are. I'll admit my biases, but I prefer the c++ way: types know how to both move and copy themselves, and they will copy by default, but move when it's safe (rvalue) or explicitly asked to (std::move). I like looking at auto u = v and knowing that u is always a copy of v.

FreeFull 11y ago
Well, if you have let u = v.clone(); then you are absolutely certain that u is a copy of v too (And it works on more types than just simple copying would).
- quicknir 11y ago
  Yes, of course you can do that, but you lose certain things. In C++ you can write code (e.g constructors) that will do the right thing with their arguments, move or copy, based on whether the input is an rvalue or not. Is there a way to get this behavior in rust?
  - FreeFull 11y ago
    In Rust, move semantics are assumed by default, and it's up to the caller to make a copy using .clone() if they want to keep ownership of the value (unless they know Copy is implemented and it's unnecessary, for example for integer types).
dbaupp 11y ago
u = v is always the same thing in Rust: semantically a shallow byte copy ala memcpy (although there may not actually be a byte-by-byte copy at runtime, due to optimisations etc.). Whether a type moves or copies doesn't change this, it only influences whether v is usable (statically checked) after the assignment: the worst that happens if you don't know what type they are is a compile error talking about "use of moved value" (which also points to exactly the place that did the move). The `Copy` trait (types that don't move) is just for types where memcpy is a valid & safe way to duplicate values of those types, it's not at all like C++'s custom copy constructors. See also my answer here: http://stackoverflow.com/a/24253573/1256624 http://stackoverflow.com/a/24253573/1256624

FreeFull 11y ago

Well, if you have let u = v.clone(); then you are absolutely certain that u is a copy of v too (And it works on more types than just simple copying would).

quicknir 11y ago
Yes, of course you can do that, but you lose certain things. In C++ you can write code (e.g constructors) that will do the right thing with their arguments, move or copy, based on whether the input is an rvalue or not. Is there a way to get this behavior in rust?
- FreeFull 11y ago
  In Rust, move semantics are assumed by default, and it's up to the caller to make a copy using .clone() if they want to keep ownership of the value (unless they know Copy is implemented and it's unnecessary, for example for integer types).

dbaupp 11y ago

u = v is always the same thing in Rust: semantically a shallow byte copy ala memcpy (although there may not actually be a byte-by-byte copy at runtime, due to optimisations etc.). Whether a type moves or copies doesn't change this, it only influences whether v is usable (statically checked) after the assignment: the worst that happens if you don't know what type they are is a compile error talking about "use of moved value" (which also points to exactly the place that did the move). The `Copy` trait (types that don't move) is just for types where memcpy is a valid & safe way to duplicate values of those types, it's not at all like C++'s custom copy constructors. See also my answer here: http://stackoverflow.com/a/24253573/1256624 http://stackoverflow.com/a/24253573/1256624