How to force a move of a type which implements the Copy trait?

Question

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 the Clone 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.

Answer 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 where b is not Copy
• let a = b where b is Copy
• let a = b.clone() where b is Clone

Note: There is no meaningful difference between assignment and initialization (like in C++) - assignment just first drops the old value.

Note: Function call arguments work just like assignment. f(b) assigns b to the argument of f.

---

First things first.

The a = b always performs a memcpy.

This is true in all three cases.

• When you do let a = b, b is memcpy'd into a.
• When you do let a = b.clone(), the result of b.clone() is memcpy'd into a.

---

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 and b 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 as Copy 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() memcpys 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.

Answer 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`
}

Answer 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.

Answer 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

Answer 5

At runtime, copies and moves, in Rust, have the same effect. However, at compile-time, in the case of a move, the variable which an object is moved from is marked as unusable, but not in the case of a copy.

When you're using Copy types, you always want value semantics, and object semantics when not using Copy types.

Objects, in Rust, don't have a consistent address: the addresses often change between moves because of the runtime behavior, i.e. they are owned by exactly one binding. This is very different from other languages!

Answer 6

In Rust when you use (or move, in Rust's terms) a value that is Copy, the original value is still valid. If you want to simulate the case that like other non-copyable values, to invalidate after a specific use, you can do:

let v = 42i32;
// ...
let m = v; 
// redefine v such that v is no longer a valid (initialized) variable afterwards
// Unfortunately you have to write a type here. () is the easiest,
// but can be used unintentionally.
let v: (); 
// If the ! type was stabilized, you can write
let v: !;
// otherwise, you can define your own:
enum NeverType {};
let v: NeverType;
// ...

If you later change v to something that is not Copy, you don't have to change the code above to avoid using the moved value.

Correction on some misunderstanding on the question

• The difference between Clone and Copy is NOT "shallow copy" and "deep copy" semantics. Copy is "memcpy" semantics and Clone is whatever the implementors like, that is the only difference. Although, by definition, things which require a "deep copy" are not able to implement Copy.

• When a type implements both Copy and Clone, it is expected that both have the same semantics except that Clone can have side effects. For a type that implements Copy, its Clone should not have "deep copy" semantics and the cloned result is expected to be the same as a copied result.

• As an attempt, if you want to use the closure to help, you probably wanted to run the closure, like let new_id = (move || id)();. If id is copy then id is still valid after the move, so this does not help, at all.