Trait objects and dynamic dispatch

The problem generics cannot solve

A Vec<T> holds values of one type. What if a drawing app needs a list with circles, squares and text boxes together? With generics, T must be one type. A trait object solves this: it is a value whose exact type is hidden, and all we know is that it implements a trait. You write it as dyn Trait, always behind some kind of pointer, such as Box<dyn Trait> or &dyn Trait.

trait Shape {
    fn area(&self) -> f64;
    fn name(&self) -> String;
}

struct Circle { r: f64 }
struct Square { s: f64 }

impl Shape for Circle {
    fn area(&self) -> f64 { 3.14159 * self.r * self.r }
    fn name(&self) -> String { "circle".into() }
}
impl Shape for Square {
    fn area(&self) -> f64 { self.s * self.s }
    fn name(&self) -> String { "square".into() }
}

fn main() {
    let shapes: Vec<Box<dyn Shape>> = vec![
        Box::new(Circle { r: 1.0 }),
        Box::new(Square { s: 2.0 }),
    ];
    for s in &shapes {
        println!("{} {:.2}", s.name(), s.area());
    }
}

Why behind a pointer?

Circle and Square have different sizes. A Vec needs every item to be the same size. A Box (a pointer to heap memory, module 8) is always the same size, so a Vec of boxes works. dyn Shape on its own has no known size, which is why you never see a bare dyn Shape variable.

Dynamic dispatch and the vtable

Dispatch means choosing which function to call. With generics, the compiler knows the exact type and calls the right function directly: static dispatch. With trait objects, the type is only known at run time. Each Box<dyn Shape> is a "fat pointer" made of two pointers: one to the data, and one to a vtable, a small table of that type's method addresses. A call looks up the method in the table: dynamic dispatch.

Box<dyn Shape>
  data ptr ---> Circle { r: 1.0 }
  vtable ptr -> [ area: Circle::area, name: Circle::name, drop, size ]

Generics or trait objects?

Which traits can be trait objects?

Not every trait can be used as dyn Trait. The rules were called "object safety" and are now called "dyn compatibility". In simple words: methods must take self by reference (&self or &mut self), must not return Self, and must not have their own generic type parameters. Clone, for example, is not dyn compatible because clone returns Self. The compiler gives a clear error if you break these rules.

Returning one of several types

fn make_shape(kind: &str) -> Box<dyn Shape> {
    if kind == "circle" {
        Box::new(Circle { r: 1.0 })
    } else {
        Box::new(Square { s: 1.0 })
    }
}

Common mistakes

• Writing Vec<dyn Shape>: "the size cannot be known at compile time". Use Vec<Box<dyn Shape>>.
• Forgetting the dyn keyword. In edition 2021 and later, a trait used as a type must be written dyn Trait.
• Reaching for dyn everywhere because it looks like Java. Prefer generics unless you need mixed types or run-time choice.
• Trying to make a trait object from a trait whose methods return Self or are generic.