Dynamic Dispatch & Trait Objects

Overview

Rust provides two dispatch mechanisms: static dispatch (monomorphization via generics) and dynamic dispatch (via dyn Trait and trait objects). Static dispatch is zero-cost at runtime but produces more code (code bloat). Dynamic dispatch adds a vtable lookup per call but allows heterogeneous collections. Understanding when to choose each is fundamental to idiomatic Rust.

Static dispatch (monomorphization)

When you write a generic function, the compiler generates a separate copy for each concrete type used:

fn print_value<T: std::fmt::Display>(value: &T) {
    println!("{}", value);
}

// The compiler generates:
// fn print_value_i32(value: &i32) { ... }
// fn print_value_String(value: &String) { ... }

print_value(&42);
print_value(&"hello".to_string());

The call site knows the exact function address at compile time — the linker can even inline it. This is zero-cost abstraction: you pay nothing at runtime that you wouldn't pay if you wrote the specialized versions by hand.

Monomorphization tradeoffs

Pro	Con
Zero runtime overhead	Binary size grows linearly with distinct type uses
Compiler can inline	Compile time increases
Exact type known (size, alignment)	Cannot store different types together in a collection

Dynamic dispatch (`dyn Trait`)

Dynamic dispatch uses trait objects — fat pointers containing both a data pointer and a vtable pointer:

┌────────────────────┐
│   &dyn Display     │
├──────────┬─────────┤
│ data ptr │ vtable  │   (16 bytes on 64-bit: 2 × usize)
└────┬─────┴────┬────┘
     │           │
     ▼           ▼
┌─────────┐  ┌──────────────────┐
│  data   │  │  vtable for Type │
│ (e.g.   │  ├──────────────────┤
│  i32)   │  │ drop:  <fn ptr>  │
│         │  │ size:  4         │
│         │  │ align: 4         │
│         │  │ fmt:   <fn ptr>  │
└─────────┘  └──────────────────┘

A &dyn Display is 16 bytes on 64-bit: 8 bytes for the data pointer, 8 bytes for the vtable pointer.

Using trait objects

trait Animal {
    fn speak(&self) -> &str;
    fn legs(&self) -> u32 { 4 }  // default impl
}

struct Dog;
impl Animal for Dog {
    fn speak(&self) -> &str { "woof" }
}

struct Spider;
impl Animal for Spider {
    fn speak(&self) -> &str { "..." }
    fn legs(&self) -> u32 { 8 }
}

// Heterogeneous collection — all implement Animal but are different sizes
let animals: Vec<Box<dyn Animal>> = vec![
    Box::new(Dog),
    Box::new(Spider),
];

for a in &animals {
    println!("{} ({} legs)", a.speak(), a.legs());
}

Without dyn, you cannot store Dog and Spider in the same Vec because they have different sizes.

Five forms of trait objects

Form	Size	Ownership	Use case
`&dyn Trait`	16 bytes	Borrowed	Passing reference, no ownership
`&mut dyn Trait`	16 bytes	Mutably borrowed	Mutating through the trait
`Box<dyn Trait>`	16 bytes (heap data)	Owned	Storing, returning, collections
`Arc<dyn Trait>`	16 bytes (heap data)	Shared owned	Multi-threaded shared ownership
`Pin<Box<dyn Trait>>`	16 bytes (pinned heap)	Owned + pinned	Async trait objects

Object safety

Not all traits can be made into trait objects. A trait is object-safe if all of its methods satisfy:

No Self: Sized requirement — methods cannot require a known size at the call site.
No generic type parameters on methods — the vtable can't hold a function for every possible type.
Self only in receiver position — self, &self, &mut self, Box<self>, etc. are OK; -> Self is not.
No associated constants (stable Rust limitation).

Examples of non-object-safe traits

// Non-object-safe: method has a type parameter
trait Parser {
    fn parse<T: FromStr>(&self, input: &str) -> Result<T, T::Err>;  // ✗
}

// Non-object-safe: returns Self
trait Clone {
    fn clone(&self) -> Self;  // ✗
}

// Non-object-safe: associated constant
trait Config {
    const MAX_SIZE: usize;  // ✗ (stabilized in nightly)
}

// Fix: use where Self: Sized to opt-out methods
trait Cloneable {
    fn clone_box(&self) -> Box<dyn Cloneable>;  // ✓ returns trait object
}

// Fix: explicit Sized bound
trait Parser {
    fn parse_str(&self, input: &str) -> Result<String, ParseError>;  // ✓ concrete type

    // Opt-out non-object-safe methods with Sized
    fn parse<T: FromStr>(&self, input: &str) -> Result<T, T::Err>
    where Self: Sized;  // ✓ only available when Self is known
}

When a method has where Self: Sized, it is not part of the trait object's vtable and cannot be called through dyn Trait.

Checking object safety at compile time

fn requires_object_safe<T: MyTrait + ?Sized>() {}

// The compiler will error if MyTrait is not object-safe
// This pattern is useful in libraries that need to enforce it

A raw T: MyTrait means T: MyTrait + Sized. You must add ?Sized for the compiler to check object safety.

`Sized` and `?Sized`

Sized is an auto trait — every concrete type is Sized by default. Types whose size is unknown at compile time are !Sized (unsized). The only unsized types are:

[T] — slices
dyn Trait — trait objects
str — string slices
Structs whose last field is unsized (rare)

// Implicitly T: Sized
fn concrete<T: Display>(value: &T) { ... }

// Explicitly opt out: allow unsized types
fn unsized<T: Display + ?Sized>(value: &T) { ... }

?Sized means "this type may or may not be Sized." It does NOT mean "the type is unsized" — it relaxes the default Sized bound.

Why Sized matters for generics

fn store_on_stack<T>(value: T) {
    // The compiler must know T's size to allocate the stack frame.
    // T: Sized is implied — this works.
}

fn store_on_heap<T: ?Sized>(value: Box<T>) {
    // Box<T> is always Sized (it's a pointer), even when T is not.
    // This is fine.
}

Performance comparison

Static dispatch

fn static_dispatch<T: Animal>(animal: &T) {
    animal.speak();  // direct function call — compiler can inline
}

Zero runtime overhead.
Compiler knows the exact callee — inlining possible.
Each monomorphization duplicates code.