Generic Trait Bounds

Write a generic function that formats its argument and watch it fail:

fn show<T>(value: T) {
    println!("{value}");        // error: `T` doesn't implement `std::fmt::Display`
}

T could be any type, so the compiler knows nothing about it: no methods, no traits, not even formatting. You already know how to write those behaviors — Traits and Implementations covered declaring and implementing them — so this topic is about demanding them in a signature. Stop claiming you accept everything and state what you need:

use std::fmt::Display;

fn show<T: Display>(value: T) {
    println!("{value}");        // legal: the bound guarantees Display
}

fn main() {
    show(1_i32);                // instantiates show::<i32>
    show("hi");                 // and show::<&str>
    // show(Point { x: 0, y: 0 });   // rejected: Point has no Display impl
}

A bound like T: Display is a contract in both directions. The declaration promises callers that any type they pass must implement Display; in exchange, the body may use every method Display provides. The compiler checks your side of the bargain at each call site, so a mistake surfaces where the type is chosen — not somewhere deep inside the body.

Several bounds combine with +, meaning and: T: Display + Clone + Send accepts only types implementing all three. When a signature outgrows one line, a where clause moves the constraints below it — same semantics, readable layout, and the form used on structs and impl blocks:

fn render<T, U>(t: &T, u: &U) -> String
where
    T: Display,
    U: Debug + Clone,
{
    format!("{t} {u:?}")          // both bounds usable inside
}

struct Cache<T> where T: Clone { entries: Vec<T> }   // bound lives with the type

impl<T: Clone> Cache<T> { fn duplicate(&self) -> Vec<T> { self.entries.clone() } }

(The last two forms were previewed in impl Blocks and Methods — an impl header bound makes its methods exist only for conforming types.)

Rust gives you a second spelling for the common case, impl Trait in argument position:

fn show(value: impl Display) { println!("{value}"); }

This is pure sugar for an anonymous generic parameter with the same bound — it monomorphizes identically and costs nothing at runtime. The difference is that the type has no name, and you cannot supply one at the call site:

error: cannot provide explicit generic arguments when `impl Trait` is used
       in argument position

show::<u32>(42) compiles against the generic form and fails against the sugar. Two impl Trait parameters are also independent types; whenever the signature must relate them (fn zip<A>(a: A, b: A)), you need named generics. Use impl Trait when the parameter type is incidental, named generics when the caller might need to steer inference with ::<>.

Return position is where impl Trait earns its keep:

fn summaries(items: &[Article]) -> impl Iterator<Item = String> + '_ {
    items.iter().map(|a| a.summarize())
}

The caller sees "an iterator of String" and nothing about how it is built — one concrete type is hidden behind the signature, and returning a different type in another branch is a compile error. That opacity is the opposite trade from dyn, where the implementation is picked at runtime; the comparison gets its own topic in Trait Objects and Dynamic Dispatch.

The interview staple hiding here: "what is the difference between fn f(x: impl Display) and fn f<T: Display>(x: T)?" — after type checking, none: same bound, same monomorphization, same machine code. The distinction is naming (you can write f::<u32>(..) only for the second) and where the syntax is allowed.

A bound decides what is legal inside the function. Look at the rule from both sides:

trait Summary { fn summarize(&self) -> String; }

fn report<T: Summary>(item: &T) {
    println!("{}", item.summarize());   // allowed — the bound promises it
    item.preview(40);                   // rejected — never promised anything
}

The second call fails even if every concrete type in your program happens to have a preview method: the signature only guarantees summarize, and the body is compiled against the signature, not against your call sites. The diagnostic names the fix:

error[E0599]: no method named `preview` found for type parameter `T` in the current scope
  = note: items from traits can only be used if the trait is implemented and in scope
  = help: consider restricting type parameter `T` with trait `Summary`

Read bounds as the smallest promise that makes the body compile — nothing more. Requiring Clone because you might need it later charges every caller for your uncertainty.

The other direction is where the error actually lands: a concrete type violating the contract is reported at the call site, with two spans — the declaration of the rule and the line that breaks it:

struct Point { x: i32, y: i32 }

fn show<T: Display>(value: T) { println!("{value}"); }

fn main() {
    show(Point { x: 0, y: 0 });
}

error[E0277]: `Point` doesn't implement `std::fmt::Display`
  --> src/main.rs:9:10
   |
 9 |     show(Point { x: 0, y: 0 });
   |          ^^^^^^^^^^^^^^^^^^^ the trait `std::fmt::Display` is not implemented for `Point`
   = note: required by a bound in `show`

The compiler is showing you the contract (required by a bound in show) and the breach (the argument) in one message. When you debug a missing bound, that is the reading order: find required by a bound in, then decide whether to implement the trait, convert the value (&x, x.to_string(), format!), or drop the bound from your signature if your body never needed it.

Now the payoff. Generic code is monomorphized: for every distinct type you instantiate, the compiler emits a separate copy of the function specialized to it.

show(1_i32)   →  a copy of show compiled for i32        ┐ direct call,
show("hi")    →  another copy for &str                  ┘ fully inlinable

There is no runtime type check, no vtable, no indirection: the call target is a fixed function the compiler can inline into the caller — which is why bounds are described as zero-cost. The bill arrives in binary size and compile time instead: N types over M generic functions means up to N × M copies, and a change to the function body recompiles all of them. For hot loops that trade is overwhelmingly worth it; for large codebases it is a reason generic-heavy APIs get a non-generic (often dyn) entry point.

One API-design consequence interviewers like: adding a bound to a public function is a breaking change. Every existing call site whose type lacks the new trait stops compiling, so semver-wise it lands like a signature change — tighten bounds deliberately, and prefer widening (T: Display + ?Sized) over narrowing when you must touch them.

Bounds are how the compiler proves behavior before the program runs. When the proof is impossible — because the set of implementations is only known at run time — you need the other mechanism: Trait Objects and Dynamic Dispatch.

Most "missing trait" errors come from standard-library signatures you did not write. Learn the hidden requirements and half of E0277 disappears before it appears:

Every one of these is an ordinary trait bound in a std signature — the error message is simply the compiler reading that signature back to you. The resolution ladder is short: derive or implement the trait (#[derive(Debug, PartialEq, Hash, Eq)] covers most cases), convert the value at the boundary (&x, x.to_string(), format!("{x}")), or relax your own bound if your body was not actually using it. Note the recurring shape of the message: headline naming the pair, a = help: line naming the trait, and a = note: required by a bound in … pointing at the declaration — the last line is what tells you whether the requirement came from your code or from std.

The trap that catches people next is the bound nobody wrote. Every type parameter implicitly carries Sized:

struct Drawer<T> { item: Box<T> }      // really: struct Drawer<T: Sized>

let d = Drawer { item: Box::new(Circle { r: 1.0 }) };   // Drawer<Circle>: fine
let d2: Drawer<dyn Summary> = Drawer { item: my_box };  // fails

error[E0277]: the size for values of type `dyn Summary` cannot be known at
compilation time

A trait object has no fixed layout — its size depends on the concrete type hidden behind it — so it is !Sized and cannot satisfy the implicit bound, even though Box<dyn Summary> itself is a perfectly sized pointer. The escape is written with a question mark:

struct Drawer<T: ?Sized> { item: Box<T> }   // `?` reads as "maybe Sized"

let d2: Drawer<dyn Summary> = Drawer { item: my_box };

?Sized opts out of the implicit requirement; the field must then be an indirection (Box<T>, &T, Rc<T>), because an unsized value cannot sit inline in a struct. This is exactly how the standard library stores trait objects — Box<dyn Error>, Rc<dyn Fn()> — so T: ?Sized shows up in nearly every generic type that can hold one.

Two more failure modes deserve names. Over-bounding is not a compile error but an API defect: each bound you add is a constraint every caller must satisfy, and adding one later breaks code that used to compile — bound by what the body uses, nothing else. A concrete version of the same trap hides in #[derive]: a derived Debug on struct Wrapper<T> { inner: T } generates impl<T: Debug> Debug for Wrapper<T>, bounding every type parameter even when the field does not use it. Wrapper<Circle> therefore has no Debug until Circle does, and sometimes the right repair is dropping the derive for a five-line manual impl that leaves T unconstrained. Watch generated bounds the same way you watch handwritten ones.

And bounds are not limited to traits: lifetimes join the same list (where T: Trait + 'a, T: 'a alone), which is the subject of Lifetime Bounds and Outlives Relations.

Bounds resolve the type set at compile time. When the set cannot be known until the program is running — a plugin list, a heterogeneous collection, an error boxed behind one type — compilation-time selection is impossible, and you reach for the mechanism built for it.