Copy and Drop are mutually exclusive

You have now met Copy twice: as the reason i64 survives being passed to a function, and as the reason String does not. So far it has probably felt like a list you have to memorise — integers yes, String no, &T yes, &mut T no, tuples of Copy things yes.

It is not a list. It is a theorem, and it is short enough to hold in your head:

A type may be Copy if and only if every field is Copy and the type has no destructor.

With that, you can decide for any type — including one you have not seen — whether assignment moves or duplicates. That is a much better position to be in than remembering a list, and it is the difference between predicting Rust and guessing at it.

This is an article rather than a problem for a mechanical reason: everything interesting here is a compile failure, and a submission that passes the gate cannot contain one. So we will read the errors instead of producing them. Copy the snippets into a scratch file if you want to see them yourself.

The two halves, as diagnostics

Half one: a Drop type can never be Copy — E0184

#[derive(Clone, Copy)]
struct Session { id: i32 }

impl Drop for Session {
    fn drop(&mut self) { println!("closing {}", self.id); }
}

error[E0184]: the trait `Copy` cannot be implemented for this type;
              the type has a destructor
 --> src/main.rs:2:8
  |
1 | #[derive(Clone, Copy)]
  |                 ---- in this derive macro expansion
2 | struct Session { id: i32 }
  |        ^ `Copy` not allowed on types with destructors
  |
note: destructor declared here
 --> src/main.rs:5:19

Every field of Session is Copy — it is one i32. The derive is still rejected, and the note points straight at the reason.

Half two: one non-Copy field is enough — E0204

#[derive(Clone, Copy)]
struct Record { id: i32, label: String }

error[E0204]: the trait `Copy` cannot be implemented for this type
 --> src/main.rs:2:8
  |
1 | #[derive(Clone, Copy)]
  |                 ---- in this derive macro expansion
2 | struct Record { id: i32, label: String }
  |        ^        -------------- this field does not implement `Copy`

rustc underlines the exact field. No destructor anywhere in sight; one String is enough.

let a = Session { id: 7 };
let b = a;                  // Copy: `a` is still valid

The rule stated as a decision procedure

Given any type, ask two questions:

1. Does it — or anything it contains, at any depth — have a Drop impl?
2. Is every field Copy?

If the answer is “no” and “yes”, it can be Copy. Otherwise it cannot, ever, no matter how you write the impl.

Run it on the standard library and everything falls out:

The &T / &mut T row is the one that pays for itself fastest. A &T can be handed to a dozen functions without ceremony because copying an address is harmless. A &mut T moves when you pass it — which is why you will sometimes see &mut *r (a reborrow) in code that needs to use a &mut twice. That is Track 3’s material, and the reason it works is the theorem above.

Where the rule shows up in real code

Clone on a Copy type must be trivial

If a type is Copy, then let b = a; already duplicates it by memcpy. That means a.clone() must produce the same thing as let b = a; — anything else and the two would disagree, and callers would have no way to know which one they were getting. Clippy enforces it, on by default:

#[derive(Copy)]
struct Counter { x: i32 }

impl Clone for Counter {
    fn clone(&self) -> Counter { Counter { x: self.x + 1 } }   // !
}

error: non-canonical implementation of `clone` on a `Copy` type
  |
  |     fn clone(&self) -> C { C { x: self.x + 1 } }
  |                          ^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `{ *self }`
  |
  = note: `-D clippy::non-canonical-clone-impl` implied by `-D warnings`

non_canonical_clone_impl is a suspicious-level lint, which means it is on by default and -D warnings turns it into an error. It is a nice, concrete consequence of the theorem: on a Copy type, Clone has exactly one correct body, and it is *self.

There is a companion, expl_impl_clone_on_copy (pedantic, off by default), which says the same thing more bluntly: “you are implementing Clone explicitly on a Copy type — consider deriving Clone or removing Copy“.

fn duplicate<T: Clone>(v: &[T]) -> Vec<T> { v.to_vec() }

#[derive(Clone, Copy)]
struct Pair<T> { a: T, b: T }

The consequence that matters most

Here is the practical payoff, and it is worth stating in one line:

A type gains a destructor the moment it owns a resource — and at that moment, assignment stops duplicating and starts moving.

You cannot add a String field, or an Rc, or a file handle, and keep Copy. This is a good thing, and it is the deepest reason Copy is a derive rather than something you can talk the compiler into. The set of types for which bit-duplication is meaningful is not a matter of opinion.

It also means that going from Copy to non-Copy is a breaking change to your API in a way that is invisible in the signature. Every caller that happily used one of your values twice suddenly gets E0382. If you are designing a small value type for other people to use, deciding whether it is Copy is a decision about your future, not just about today.

Where this goes next

You now have the whole rule, and the two errors that enforce each half. The next place the theorem earns its keep is Track 3, where &T being Copy and &mut T not being Copy turns out to explain roughly half of the borrow checker’s behaviour — including why a &mut sometimes seems to vanish when you pass it to a function, and what a reborrow is doing about that.