Lesson 2. Moves and Copy

Mission link: use of moved value is the first error every Rust programmer meets, and reaching for clone to silence it is the first bad habit. Both come from not knowing which types move.
Primary source: The Rust Programming Language, What is Ownership?
Prerequisites: Lesson 1

Warm-up

1. ▢ When is a value dropped, and in what order within one scope?

2. ▢ Which of let n = 5i32 and let s = String::from("x") owns a heap allocation?

Know this

Since a value has exactly one owner, assigning it to a second name would create two owners. Rust resolves that by moving: the new name becomes the owner and the old one becomes unusable.

let a = String::from("hi");
let b = a;                  // ownership moves to b
println!("{a}");            // error[E0382]: borrow of moved value: `a`

Nothing was copied and nothing was freed. The three words describing the String were written into b, and the compiler now refuses to let you use a, because allowing it would mean two names both responsible for freeing one buffer.

This is a compile-time bookkeeping rule, not a runtime operation. A move compiles to the same machine code as a copy of those three words, and often to nothing at all.

Copy types are duplicated instead

A type that is entirely plain data, with nothing to free, can implement Copy. Assignment then duplicates the value and both names stay usable:

let a = 5;
let b = a;
println!("{a} {b}");        // fine: i32 is Copy

Two rows deserve attention. &T is Copy and &mut T is not, which is why passing a &mut to a function appears to move it, and is the reason for a surprising number of stage-3 errors. And a type with a Drop implementation can never be Copy, because duplicating it would mean running the destructor twice.

Your own type gets Copy only if you ask, and only if every field allows it:

#[derive(Copy, Clone, Debug)]
struct Point { x: f64, y: f64 }

Copy requires Clone because Copy is the special case: an implicit, bit-for-bit duplication. Clone is the general case, an explicit and possibly expensive one.

Moving into and out of functions

fn consume(s: String) -> usize { s.len() }      // takes ownership, drops it
fn borrow(s: &String) -> usize { s.len() }      // looks at it

let s = String::from("hello");
consume(s);
// s is gone here

Returning a value moves ownership out, which is how a constructor works and why returning a local reference is a different matter entirely, covered in stage 4.

Partial moves

Moving one field out of a struct invalidates that field, and the struct as a whole:

struct Config { name: String, retries: u32 }

let c = Config { name: String::from("api"), retries: 3 };
let name = c.name;          // c.name moved out
println!("{}", c.retries);  // fine: u32 is Copy and was not moved
println!("{c:?}");          // error: use of partially moved value

The remaining Copy field is still readable, and the struct cannot be used as a whole. That precision is deliberate, and it is why the error says partially moved.

The four honest answers to a move error

When the compiler says a value was moved, one of these is the fix, and they are in rough order of preference:

1. Borrow instead of moving. Change the signature to &T. This is right whenever the callee only needs to read.
2. Return it back. Take ownership and return the value, or a value derived from it, when the callee genuinely consumes it.
3. Restructure so one owner is enough. Often the move error is a design question wearing a compiler error's clothes.
4. Clone. Correct when you genuinely need two independent values, and a real allocation every time.

clone is last on that list rather than absent. Written deliberately, it says "two independent values are worth an allocation here". Written reflexively, it hides the question the compiler was asking, and the answer would usually have been number 1.

Practice

1. ▢ Which of these compile?

   // A
   let a = String::from("x");
   let b = a;
   println!("{b}");
   
   // B
   let a = String::from("x");
   let b = a;
   println!("{a}");
   
   // C
   let a = 5;
   let b = a;
   println!("{a} {b}");
   

2. ▢ Predict whether this compiles, and why.

   fn takes(s: String) {}
   
   fn main() {
       let s = String::from("hi");
       takes(s);
       takes(s);
   }
   

3. ▢ Which of these types are Copy?

   • a) [u8; 4]
   • b) &mut i32
   • c) (bool, char)
   • d) Option<String>

4. ▢ What exactly does this error mean, and what is the most likely correct fix?

   error[E0382]: borrow of moved value: `config`
   

5. ▢ A colleague fixes every move error by adding .clone() and says the compiler is satisfied so the code is correct. What is right and what is wrong about that?

Real-world reps

• [ ] Write case B from practice 1 and read the full error, including the notes and the span markers. It names the line that moved the value, which is the part people skip.
• [ ] Take a function that accepts String and change it to &str. Fix the call sites. Notice how many clones disappear.
• [ ] Tomorrow: write a struct with one String field and one u32 field, move the String out, and try to use each field and then the whole struct. Three different errors, all informative.

Going further

• What is Ownership?: moves, clones and the stack-heap distinction, with diagrams
• Copy: what the trait requires, and why it implies Clone
• E0382: the error code, with a minimal reproduction and the suggested fixes
• Ownership and borrowing: the Copy table and the error index, for lookup
• Resources

Not landing? Reread the primary source at the top, since this lesson compresses it and compression is where understanding leaks. Check the glossary for any term that felt slippery.

If the lesson itself is unclear rather than the material, that is a defect: open an issue.