Trait Objects and Dynamic Dispatch

You are drawing figures in a renderer, and the set of figures is not closed: Circle and Rect today, Bezier and Text added by a plugin next month. The first instinct is an enum:

enum Shape { Circle(f64), Rect(f64, f64) }   // every addition edits this enum
// and every `match` over it, in every crate that sees it

An enum is the right tool when you own the closed set of variants. It is the wrong tool here: each new figure is a change to a central type plus every exhaustive match against it — the opposite of open extension. Traits already solved the behavior side; the missing piece is storage: a Vec that holds different implementors at once. That is what a trait object is — a value whose concrete type is chosen at run time:

trait Shape {
    fn area(&self) -> f64;
    fn name(&self) -> &'static str;
}

struct Circle { r: f64 }
struct Rect   { w: f64, h: f64 }

impl Shape for Circle {
    fn area(&self) -> f64 { std::f64::consts::PI * self.r * self.r }
    fn name(&self) -> &'static str { "circle" }
}
impl Shape for Rect {
    fn area(&self) -> f64 { self.w * self.h }
    fn name(&self) -> &'static str { "rect" }
}

fn main() {
    let shapes: Vec<Box<dyn Shape>> = vec![
        Box::new(Circle { r: 1.0 }),      // Box<Circle> coerces to Box<dyn Shape>
        Box::new(Rect { w: 2.0, h: 3.0 }),
    ];
    let total: f64 = shapes.iter().map(|s| s.area()).sum();   // one code path
    println!("{} shapes, {} total area", shapes.len(), total);
}

Box<Circle> becomes Box<dyn Shape> by unsized coercion at the point where the type annotation demands it — no .into(), no wrapper enum, and the heap allocation still holds the real Circle. Note what does not work: Vec<dyn Shape> is illegal, because a dynamically sized value cannot be stored inline in a vector's buffer. The element type must be sized, so the collection holds pointers instead: Vec<Box<dyn Shape>> for owned values, Vec<&dyn Shape> for a borrowed view over data that lives elsewhere.

Layout is the part interviewers ask about. A dyn Shape reference is a fat pointer — two pointer-width words:

&dyn Shape / Box<dyn Shape>      16 bytes on a 64-bit target
┌──────────────┬──────────────┐
│  data ptr    │  vtable ptr  │   → concrete Circle on the heap
└──────────────┴──────────────┘      → read-only table emitted by the compiler
                                      [size, align, drop glue, area(), name(), …]

The data pointer targets the value itself; the vtable pointer targets a table the compiler generates once per (trait, type) pair — every Circle in the program shares one Shape vtable, so memory cost is not per instance. A call like s.area() loads the vtable pointer from the fat pointer, indexes the slot for area, and calls through it with the data pointer as self. Everything you can infer from that picture — why the concrete type can change between elements, why the compiler cannot inline the call, why Box<dyn Shape> itself is perfectly sized — follows from those two words.

One syntax rule is enforced since the 2021 edition: the dyn keyword is mandatory. Writing Box<Shape> is rejected with error[E0782]: trait objects must include the dyn keyword, which exists to keep a plain generic type name from silently meaning "possible trait object" in old code.

The previous topic built the static half — Generic Trait Bounds fixes types at compile time. This is the dynamic half: the type is data, not a compile-time fact. That freedom has a price list, and the compiler will not let you pay it until the trait qualifies.

Not every trait can be turned into a vtable. Try to store a clonable value behind dyn:

trait Clonable {
    fn clone_value(&self) -> Self;      // returns the implementor's own type
}

fn duplicate(item: &dyn Clonable) { /* item.clone_value() — clone into what? */ }

error[E0038]: the trait `Clonable` cannot be made into an object

The reason is mechanical: a vtable entry must be callable with nothing but the data pointer and the table — no knowledge of the concrete type, no generics, no surprises about size. A method that fails that test disqualifies the whole trait, and there are only a handful of ways to fail:

Note the nuance in that last row: a method may opt itself out of object safety instead of killing the trait:

trait Shape {
    fn area(&self) -> f64;                                  // in the vtable
    fn translate(self, dx: f64, dy: f64) -> Box<dyn Shape>
        where Self: Sized;                                  // only on concrete types
}

dyn Shape compiles and exposes area; translate simply does not exist on a trait object, because it was gated behind Self: Sized. This is exactly how std::iter::Iterator gets away with dozens of methods that take self by value or generic parameters (count, last, chain, map) while dyn Iterator still works: every one of them carries where Self: Sized. The trait stays object-safe; the heavy machinery stays on concrete iterators.

When you meet E0038 in review, there are three standard repairs, in the order you should try them:

// 1. Return a boxed value instead of Self — the classic clone_box pattern
fn duplicate(&self) -> Box<dyn Shape>;

// 2. Replace a generic parameter with a trait object parameter
fn encode(&self, w: &mut dyn Write);        // was: fn encode<W: Write>(&self, w: &W)

// 3. Gate the method: keep it for concrete types, drop it from dyn
fn with_area(&self, extra: f64) -> Self where Self: Sized;

All three preserve the object-safe subset while moving the impossible parts to call sites where the concrete type is known. One repair people miss: keep by-value semantics by reboxing the receiver — fn into_parts(self: Box<Self>) is object-safe, because the compiler can move out of a sized box using only the data pointer, while plain self cannot move out of an unsized value. Also remember the cascade: a trait with supertraits needs every supertrait to be object-safe too, because dyn Sub must expose the inherited methods from the same table.

The proof that these rules are workable rather than restrictive is std itself: Display, Iterator, Error, and the Fn traits are all object-safe, which is why Box<dyn Error> and Box<dyn Fn(&str) -> bool> are everyday types — every closure-capturing callback you have ever boxed rode through one of these vtables.

Object safety is the admission ticket; the price of admission is paid at every call site.

Take the same s.area() call written two ways and follow what the machine does:

fn total_generic<T: Shape>(items: &[T]) -> f64 {       // static dispatch
    items.iter().map(|s| s.area()).sum()
}

fn total_dyn(items: &[&dyn Shape]) -> f64 {            // dynamic dispatch
    items.iter().map(|s| s.area()).sum()
}

The generic version is monomorphized: the compiler knows the concrete type of T, resolves area to a fixed address, and can inline it straight into the loop — after which the call disappears entirely. The dyn version loads the vtable pointer out of the fat pointer, indexes the area slot, and performs an indirect branch the CPU cannot predict from the opcode alone. The body of area is identical; only how the target is found differs.

Choosing well is about where the decision happens, not about which is "faster" in the abstract. Reach for dyn when the type set is genuinely open — a Vec<Box<dyn Shape>>, a widget tree, a registry of command handlers — or when you want the concrete type out of the public signature so adding an implementation does not recompile callers. Reach for generics when the set is closed and the call sits in a loop that runs millions of times; there, an uninlinable indirect call per iteration is a real cost you can measure. And remember the third option from Enumerations with Data: a plain enum plus match gives you one closed set with no vtable and fully inlined dispatch — often the best answer for two or three variants, and it forces the exhaustiveness check every time you add a fourth.

Two facts round out daily usage. First, trait objects accept marker bounds and lifetimes like any other bound: Box<dyn Fn(&str) -> bool + Send + 'static> is a thread-safe callback, and Box<dyn Error + Send + Sync + 'static> is the shape anyhow::Error wraps. Second, the object lifetime default decides how long the referent must live: &'a dyn Trait defaults to 'a, while Box<dyn Trait> defaults to 'static — which is why Box<dyn Error> inside a main that returns Result refuses borrowed errors, and why a callback that captures borrowed data must spell its lifetime out:

fn log_box<'a>(msg: &'a str) -> Box<dyn Fn() + 'a> {   // bare Box<dyn Fn()> would demand 'static
    Box::new(move || println!("{msg}"))
}

Write the bound explicitly (+ 'a) and the borrowed data is legal; omit it and the closure is rejected for not living forever. The rule is small, and knowing it saves an afternoon of fighting a 'static requirement that was never really a requirement.

Dispatch is now a dial, not a fork: bounds choose types at compile time, dyn chooses at run time, enums sidestep both. The next topic moves from designing failure-prone signatures to handling what happens when they fail anyway: unwrap, expect, and When Panics Are Acceptable.