16.5Deriving traits

Last updated June 13, 2026

For many common traits, the implementation is mechanical: there's an obvious correct version the compiler can write from your type's definition. #[derive(...)] is how you ask it to. You've used derive since lesson 10.7 for Debug; now that you know what a trait is, this lesson tours the derivable traits and what each one gives you. Think of it as the menu.

How derive works

#[derive(Trait)] above a type tells the compiler: "write the standard implementation of Trait for this type." It works field by field, deriving the trait for the whole struct or enum by combining its behavior on each field. That's why a struct can only derive a trait if all its fields already implement it; the derived implementation is built out of the fields' implementations.

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

This one line gives Point three behaviors: printable with {:?}, cloneable with .clone(), and comparable with ==. Each would be tedious and error-prone to write by hand, and the compiler's version is exactly what you'd write anyway.

The tour

The traits you can derive, and what each unlocks:

Debug enables {:?} and {:#?} formatting (lesson 10.7) and makes the type usable with dbg! and assert_eq! failure messages. Derive it on essentially every type; the cost is nothing and the debugging payoff is constant.

Clone enables .clone(), an explicit deep copy (lesson 8.7). Derive it when you need independent copies of a value.

Copy makes the type copy implicitly on assignment instead of moving (lesson 8.5). It requires Clone too (#[derive(Copy, Clone)] together) and is only allowed when every field is Copy, so a struct containing a String can never be Copy. Derive it on small, all-Copy types like a Point of numbers.

PartialEq enables == and !=. Eq is a marker added on top (#[derive(PartialEq, Eq)]) that promises equality is "total", every value equals itself, which floats notably don't satisfy because NaN != NaN (lesson 4.5). So a type with an f64 field can derive PartialEq but not Eq.

PartialOrd enables the comparison operators <, >, <=, >= (the trait that finished largest in lesson 16.3). Ord adds total ordering on top (requires Eq and PartialOrd), needed to sort or to use as a sorted-collection key. For a struct, the derived ordering compares fields in declaration order, like comparing tuples.

Hash lets a type be used as a HashMap key (lesson 18.6).

Default provides ::default(), every field at its default value (lesson 10.6).

A common derive set

In practice a few derives appear together so often they're almost reflexive. For a plain data type you'll frequently write:

#[derive(Debug, Clone, PartialEq)]
struct Config {
    name: String,
    retries: u32,
}

Debug for inspection, Clone for making copies, PartialEq so you can compare (and so assert_eq! works in tests, lesson 14.2). Add Default if a "zeroed" instance makes sense, Eq + Hash if it'll be a map key, Copy + Clone if it's small and all-Copy. You add derives as you discover you need the capability; the compiler's error messages tell you which trait is missing when you try to do something the type can't yet.

When you can't derive

Two situations stop a derive. First, a field doesn't implement the trait: you can't derive Clone for a struct whose field isn't Clone, because the field-by-field implementation has nothing to call. The fix is to make the field cloneable or implement Clone by hand. Second, the derived behavior isn't what you want: the mechanical version is correct but not appropriate, for instance two Color values that should compare equal if their RGB matches regardless of an attached name field. When the obvious implementation is wrong for your type, skip the derive and write impl Trait for Type by hand, exactly as you did for Summary in lesson 16.1. Derive is a convenience, never an obligation.

Quiz time

Question #1

Why can a struct derive a trait only if all its fields implement that trait?

Question #2

Your struct has an f64 field. Can you derive PartialEq? Can you derive Eq? Why?

Question #3

When should you write a trait implementation by hand instead of deriving it?

Display was the one trait this lesson said you can't derive. The next lesson implements it by hand, the controlled, human-facing {} output you've wanted since lesson 10.7, and the Rust version of C++'s "overloading operator<<."