Dispatch and monomorphisation

Lesson 3.2 said a trait is a constraint. This lesson is what the compiler does with the constraint, and it is where Rust’s most-discussed engineering trade-offs come from.

Monomorphisation

fn largest<T: PartialOrd>(items: &[T]) -> &T {
    let mut best = &items[0];
    for x in items { if x > best { best = x; } }
    best
}

fn main() {
    println!("{}", largest(&[1i32, 5, 3]));
    println!("{}", largest(&[1.5f64, 0.2]));
    println!("{}", largest(&["a", "z"]));
    println!("{}", largest(&[10i32, 20]));
}

fn largest_i32(items: &[i32]) -> &i32 { /* ... */ }
fn largest_f64(items: &[f64]) -> &f64 { /* ... */ }
fn largest_str(items: &[&str]) -> &&str { /* ... */ }

Everything downstream follows from this.

It is fast. Each copy knows its concrete type, so x > best is a direct comparison with no indirection, and the whole function can be inlined into the caller. Generic Rust runs exactly as fast as the hand-written version, which is the actual meaning of “zero-cost abstraction”: you could not have done better by hand.

It is expensive to compile. The compiler does real work per instantiation, and generic code in a heavily-used library multiplies fast. When someone complains that Rust builds slowly, monomorphisation is a large part of the answer — along with LLVM optimising every one of those copies separately.

It makes binaries large. A generic function used with forty types produces forty bodies. cargo bloat will show you exactly this, and running it once on a real project is worth more than reading about it.

It cannot be stored heterogeneously. Vec<T> holds one T. If you need a vector of different types that share a trait, monomorphisation cannot help — each would be a different type and a different Vec.

That last constraint is what forces the other mechanism to exist.

Dynamic dispatch

let shapes: Vec<Box<dyn Draw>> = vec![
    Box::new(Circle { r: 1.0 }),
    Box::new(Square { s: 2.0 }),
];

dyn Draw is a type — the one built from the trait. It is dynamically sized (1.2), so it lives behind a pointer, and that pointer is fat:

Box<dyn Draw>
┌──────────────┬──────────────┐
│ data pointer │ vtable ptr   │
└──────┬───────┴──────┬───────┘
       │              │
       ▼              ▼
  the Circle     ┌──────────────────┐
  (heap)         │ drop_in_place    │
                 │ size, align      │
                 │ draw()           │  ← the trait's methods
                 └──────────────────┘

Calling .draw() loads the function pointer from the vtable and calls through it. One extra indirection, and — usually more important — the call cannot be inlined, which also blocks the optimisations inlining would have enabled.

The honest summary for a design discussion: the per-call cost of dyn is usually irrelevant, and the compile-time and binary-size cost of generics is usually not. An indirect call is a couple of nanoseconds. Teams reach for dyn in application code — error types, plugin registries, trait-object collections — and reserve generics for hot paths and library APIs. If you take one tech-lead-usable opinion from this lesson, that is it.

impl Trait means two different things

This trips people up because the syntax is identical and the meaning is nearly opposite.

fn print_all(items: impl IntoIterator<Item = String>) { }   // argument position
fn make() -> impl Iterator<Item = u32> { 0..10 }            // return position

In argument position, impl Trait is sugar for an anonymous generic parameter. It is the same as fn print_all<I: IntoIterator<Item = String>>(items: I). The caller chooses the type.

In return position, it is an opaque type. The function returns one specific concrete type, but the caller is not told which — only that it satisfies the bound. The function chooses the type.

The return-position form exists because iterator and closure types are unnameable. 0..10 mapped by a closure has a type like Map<Range<u32>, {closure@src/main.rs:3:14}>, which you cannot write down. impl Iterator lets you return it without naming it, with no boxing and no dynamic dispatch.

Two consequences worth knowing when reading:

• You cannot return two different concrete types from a function returning impl Trait, even in different branches — there is one hidden type, not a choice. If you need branches, you need Box<dyn Trait>.
• It is an API commitment. The caller cannot name the type, so you can change it freely — but they can rely on the traits you named, so adding is safe and removing is breaking.

Dyn compatibility

Not every trait can become a dyn Trait. The trait must be dyn-compatible, which until Rust 1.84 was called object safety — you will hear both, and knowing the rename is current is a small credibility marker.

The rules exist for one reason: a vtable must have a fixed layout, decided once, without knowing the concrete type. Anything preventing that is disqualifying.

// A
trait Draw { fn draw(&self); }

// B
trait Container { fn add<T>(&mut self, item: T); }

// C
trait Cloneable { fn duplicate(&self) -> Self; }

// D
trait Named { fn name(&self) -> String; fn id(&self) -> u64 { 0 } }

trait Container {
    fn add<T>(&mut self, item: T) where Self: Sized;
    fn len(&self) -> usize;
}

fn run<P: Plugin>(p: P)              // A
fn run(p: &dyn Plugin)               // B

What you should now be able to say

• Monomorphisation duplicates generic code per concrete type. That single fact explains Rust’s speed, its build times, and its binary sizes.
• dyn Trait is a type, dynamically sized, behind a fat pointer carrying a vtable.
• Dynamic dispatch costs an indirect, non-inlinable call — and saves compile time and binary size.
• impl Trait in argument position: caller picks. In return position: function picks, and the type is opaque.
• Dyn compatibility (formerly object safety) is about whether a fixed vtable layout is possible. where Self: Sized excludes a method from it.

Next: 3.4 — Where does this method come from?