How to force a move of a type which implements the Copy trait?
Solution 1
I don't really understand your question, but you certainly seem confused. So I'll address what seems to be the root of this confusion:
The C++ notions of copy/move I think I get correctly, but this 'everything is a memcpy anyway' is, well, it hasn't been very intuitive any time I read it
When thinking about Rust's move semantics, ignore C++. The C++ story is way more complicated than Rust's, which is remarkably simple. However, explaining Rust's semantics in terms of C++ is a mess.
TL;DR: Copies are moves. Moves are copies. Only the type checker knows the difference. So when you want to "force a move" for a
Copy
type, you are asking for something you already have.
So we have three semantics:
-
let a = b
whereb
is notCopy
-
let a = b
whereb
isCopy
-
let a = b.clone()
whereb
isClone
Note: There is no meaningful difference between assignment and initialization (like in C++) - assignment just first
drop
s the old value.
Note: Function call arguments work just like assignment.
f(b)
assignsb
to the argument off
.
First things first.
The a = b
always performs a memcpy
.
This is true in all three cases.
- When you do
let a = b
,b
ismemcpy
'd intoa
. - When you do
let a = b.clone()
, the result ofb.clone()
ismemcpy
'd intoa
.
Moves
Imagine b
was a Vec
. A Vec
looks like this:
{ &mut data, length, capacity }
When you write let a = b
you thus end up with:
b = { &mut data, length, capacity }
a = { &mut data, length, capacity }
This means that a
and b
both reference &mut data
, which means we have aliased mutable data.
The type-system doesn't like this so says we can't use b
again. Any access to b
will fail at compile-time.
Note:
a
andb
don't have to alias heap data to make using both a bad idea. For example, they could both be file handles - a copy would result in the file being closed twice.
Note: Moves do have extra semantics when destructors are involved, but the compiler won't let you write
Copy
on types with destructors anyway.
Copies
Imagine b
was an Option<i32>
. An Option<i32>
looks like this:
{ is_valid, data }
When you write let a = b
you thus end up with:
b = { is_valid, data }
a = { is_valid, data }
These are both usable simultaneously. To tell the type system that this is the case, one marks Option<i32>
as Copy
.
Note: Marking something copy doesn't change what the code does. It only allows more code. If you remove a
Copy
implementation, your code will either error or do exactly the same thing. In the same vein, marking a non-Copy
type asCopy
will not change any compiled code.
Clones
Imagine you want to copy a Vec
, then. You implement Clone
, which produces a new Vec
, and do
let a = b.clone()
This performs two steps. We start with:
b = { &mut data, length, capacity }
Running b.clone()
gives us an additional rvalue temporary
b = { &mut data, length, capacity }
{ &mut copy, length, capacity } // temporary
Running let a = b.clone()
memcpy
s this into a
:
b = { &mut data, length, capacity }
{ &mut copy, length, capacity } // temporary
a = { &mut copy, length, capacity }
Further access of the temporary is thus prevented by the type system, since Vec
is not Copy
.
But what about efficiency?
One thing I skipped over so far is that moves and copies can be elided. Rust guarantees certain trivial moves and copies to be elided.
Because the compiler (after lifetime checking) sees the same result in both cases, these are elided in exactly the same way.
Solution 2
Wrap the copyable type in another type that doesn't implement Copy
.
struct Noncopyable<T>(T);
fn main() {
let v0 = Noncopyable(1);
let v1 = v0;
println!("{}", v0.0); // error: use of moved value: `v0.0`
}
Solution 3
New Answer
Sometimes I just want it to scream at me "put a new value in here!".
Then the answer is "no". When moving a type that implements Copy
, both the source and destination will always be valid. When moving a type that does not implement Copy
, the source will never be valid and the destination will always be valid. There is no syntax or trait that means "let me pick if this type that implements Copy
acts as Copy
at this time".
Original Answer
I just want to sometimes say "yeah, this type is Copy, but I really don't need this value in this variable anymore. This function takes an arg by val, just take it."
It sounds like you are trying to do the job of the optimizer by hand. Don't worry about that, the optimizer will do that for you. This has the benefit of not needing to worry about it.
Solution 4
Moves and copies are basically just the same runtime operation under the covers. The compiler inserts code to make a bitwise copy from the first variable's address into the second variable's address. In the case of a move, the compiler also invalidates the first variable so that if it subsequently used it will be a compile error.
Even so, I think there would be still be validity if Rust language allowed a program to say the assignment was an explicit move instead of a copy. It could catch bugs by preventing inadvertant references to the wrong instance. It might also generate more efficient code in some instances if the compiler knows you don't need two copies and could jiggle the bindings around to avoid the bitwise copy.
e.g. if you could state a = move
assignment or similar.
let coord = (99.9, 73.45);
let mut coord2 = move coord;
coord2.0 += 100.0;
println!("coord2 = {:?}", coord2);
println!("coord = {:?}", coord); // Error
Related videos on Youtube
Noein
Updated on September 14, 2022Comments
-
Noein over 1 year
A custom type by default is moved through default assignment. By implementing the
Copy
trait, I get "shallow copy semantics" through default assignment. I may also get "deep copy semantics" by implementing theClone
trait.Is there a way to force a move on a
Copy
type?I tried using the
move
keyword and a closure (let new_id = move || id;
) but I get an error message. I'm not into closures yet, but, from seeing them here and there, I thought that that would have worked.-
Shepmaster almost 9 yearsThere's no benefit to leaving something as uninitialized, other than trying to open up holes in your program. I think you need to tell us why you want to do the things you want to do, as it doesn't make any sense. :-)
-
-
Noein almost 9 yearsNo, no. Sometimes I just want it to scream at me "put a new value in here!". Certainly not trying to optimize; esp. given that I still don't get the technical difference between
Copy
and!Copy
under-the-hood (i.e. "everything is a memcpy anyway; just sometimes shallow and sometimes deep, but there's little intuition about it."). -
Noein almost 9 yearsRight. An answer's an answer even if it's not to the asker's heart :/
-
Shepmaster almost 9 years@Noein true, but chances are that you have a real question that prompted this question. I'd like to avoid the XY Problem.
-
jocull almost 9 yearsMaybe the original question was just a reaction to "Copy" seeming like it would be a slow thing. If I copy a file it takes awhile, but if I move a file it's fast. So by trying to prevent copying I might be trying to go for a speed increase (though the answers and comments make it clear there is none to be had)
-
Noein almost 9 yearsHuh, great answer! I think I get it now. Though
clone
, after a bit of playing around, now seems like the magical bit in all of this. I tried to impl it for a local type the same way it's impl'd here but it errors because I'm trying to pass by value a non-copy type that I'm only borrowing. So, where could the cloning be happening for any complex type?! (note: not a bug in my setup;#[derive(...)]
works.) -
Veedrac almost 9 yearsThat
Clone
implementation just redirects toCopy
. If your type is not copyable, you're going to have to be a bit cleverer about it.#[derive(clone)]
willClone
each struct member, for example. -
Noein almost 9 years
-
Veedrac almost 9 years@Noein
Copy
requiresClone
because there's no reason to implement justCopy
. If someone wants to acceptT: Clone
, it'd be silly if they couldn't acceptCopy
types too. The compiler error is just to stop people forgetting. -
johnbakers almost 6 yearsIt would seem to a Rust novice such as myself that when you say "object's don't have a consistent address" because of the runtime, this would be a lot less efficient by having extra allocations and copying happening to ensure only one binding owns the memory.
-
Shepmaster almost 6 yearsboth have the same semantics except — I disagree: if something implements
Copy
, thenClone
should always delegate to theCopy
implementation. There is no good reason to haveClone
do something different fromCopy
. -
Earth Engine almost 6 yearsEmm... What about a
println!
invocation? This is what I said "side-effects". -
stu over 4 yearsso perhaps you can explain how one is supposed to divine what's going on? I'm a rust newbie and I thought the point was to be as clear and as exact as possible, to avoid pitfalls at runtime. From what you're saying, I can look at a line of code that does an assignment and have no idea if it's doing a copy and leaving the original intact or doing a move and making the original unusable. By having some syntactic marker, the author would be able to make it clear in the code that it was specifically being moved.
-
Shepmaster over 4 years@stu One of the reasons that the
Copy
trait exists is because leaving something unusable doesn't make sense for certain types, such as plain integers or booleans. While it's true that you might not be able to look at a line and tell, the compiler will quickly provide an error stating that you are trying to use a moved non-Copy
value, so you don't have to do any thinking yourself.