1# Chapter 6 - Generics, Dynamic Dispatch and Static Dispatch
2 
3> Static where you can, dynamic where you must
4 
5Rust allows you to handle polymorphic code in two ways:
6* **Generics / Static Dispatch**: compile-time, monomorphized per use.
7* **Trait Objects / Dynamic Dispatch**: runtime vtable, single implementation.
8 
9Understanding the trade-offs lets you write faster, smaller and more flexible code.
10 
11## 6.1 [Generics](https://doc.rust-lang.org/book/ch10-00-generics.html)
12 
13Every programming language has tools for effectively handling the duplication of concepts. In Rust, one such tool is generics: abstract stand-ins for concrete types or other properties. We can express the behavior of generics or how they relate to other generics without knowing what will be in their place when compiling and running the code. 
14 
15We use generics to create definitions for items like function signatures or structs, which we can then use with many different concrete data types. Let's first look at how to define functions, structs, enums, and methods using generics. Generics can also be used to implement Type State Pattern and constrain a struct functionality to certain expected types, more on type state on [Chapter 7](./chapter_07.md).
16 
17[Generics by Examples](https://doc.rust-lang.org/rust-by-example/generics.html).
18 
19### Generics Performance
20 
21You might be wondering whether there is a runtime cost when using generic type parameters. The good news is that using generic types won't make your program run any slower than it would with concrete types. Rust accomplishes this by performing monomorphization of the code using generics at compile time. Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when compiled. The compiler checks for all occurrences of the generic parameter and generates code for the concrete types the generic code is called with.
22 
23## 6.2 Static Dispatch: `impl Trait` or `<T: Trait>`
24 
25A static dispatch is basically a constrained version of a generics, a trait bounded generic, at compile-time it is able to check if your generic satisfies the declared traits.
26 
27### ✅ Best when:
28* You want **zero runtime cost**, by paying the compile time cost.
29* You need **tight loops or performance**.
30* Your types are **known at compile time**.
31* Your are working with **single-use implementations** (monomorphized).
32 
33### 🏎️ Example: High-performance function with generic
34```rust
35fn specialized_sum<T: MyTrait, U: Iterator<Item = T>>(iter: U) -> T {
36    iter.map(|x| x.random_mapping()).sum()
37}
38 
39// or, equivalent, more modern
40fn specialized_sum<T: MyTrait>(iter: impl Iterator<Item = T>) -> T {
41    iter.map(|x| x.random_mapping()).sum()
42}
43```
44 
45This is compiled into **specialized machine code** for each usage, fast and inlined.
46 
47## 6.3 Dynamic Dispatch: `dyn Trait`
48 
49Usually dynamic dispatch is used with some kind of pointer or a reference, like `Box<dyn Trait>`, `Arc<dyn Trait>` or `&dyn trait`.
50 
51### ✅ Best when:
52* You absolutely need runtime polymorphism.
53* You need to **store different implementations** in one collection.
54* You want to **abstract internals behind a stable interface**.
55* You are writing a **plugin-style architecture**.
56 
57> ❗ Closer to what you would get in an object oriented language and can have some heavy costs associated to it. Can avoid generic entirely and let you mix types that implement the same traits.
58 
59### 🚚 Example: Heterogeneous collection
60 
61```rust
62trait Animal {
63    fn greet(&self) -> String;
64}
65 
66struct Dog;
67impl Animal for Dog {
68    fn greet(&self) -> String {
69        "woof".to_string()
70    }
71}
72 
73struct Cat;
74impl Animal for Cat {
75    fn greet(&self) -> String {
76        "meow".to_string()
77    }
78}
79 
80fn all_animals_greeting(animals: Vec<Box<dyn Animal>>) {
81    for animal in animals {
82        println!("{}", animal.greet())
83    }
84}
85```
86 
87## 6.4 Trade-off summary
88 
89| | Static Dispatch (impl Trait) | Dynamic Dispatch (dyn Trait) |
90|------------------- |------------------------------ |---------------------------------- |
91| Performance | ✅ Faster, inlined | ❌ Slower: vtable indirection |
92| Compile time | ❌ Slower: monomorphization | ✅ Faster: shared code |
93| Binary size | ❌ Larger: per-type codegen | ✅ Smaller |
94| Flexibility | ❌ Rigid, one type at a time | ✅ Can mix types in collections |
95| Use in trait fn() | ❌ Traits must be object-safe | ✅ Works with trait objects |
96| Errors | ✅ Clearer | ❌ Erased types can confuse errors |
97 
98* Prefer generics/static dispatch when you control the call site and want performance.
99* Use dynamic dispatch when you need abstraction, plugins or mixed types. 🚨 Runtime cost.
100* If you are not sure, start with generics, trait bound them - then use `Box<dyn Trait>` when flexibility outweighs speed.
101 
102> Favor static dispatch until your trait needs to live behind a pointer.
103 
104## 6.5 Best Practices for Dynamic Dispatch
105 
106Dynamic dispatch `Ptr<dyn Trait>` is a powerful tool, but it also has significant performance trade-offs. You should only reach for it when **type erasure or runtime polymorphism** are essential. It is important to know when you need Trait Objects:
107 
108### ✅ Use Dynamic Dispatch When:
109 
110* You need heterogeneous types in a collection:
111```rust
112fn all_animals_greeting(animals: Vec<Box<dyn Animal>>) {
113    for animal in animals {
114        println!("{}", animal.greet())
115    }
116}
117```
118 
119* You want runtime plugins or hot-swappable components.
120* You want to abstract internals from the caller (library design).
121 
122 
123### ❌ Avoid Dynamic Dispatch When:
124 
125* You control the concrete types.
126* You are writing code in performance critical paths.
127* You can express the same logic in other ways while keeping simplicity, e.g. generics.
128 
129## 6.6 🚨 Trait Objects Ergonomics
130 
131* Prefer `&dyn Trait` over `Box<dyn Trait>` when you don't need ownership.
132* Use `Arc<dyn Trait>` for shared access across threads.
133* Don't use `dyn Trait` if the trait has methods that return `Self`.
134* **Avoid boxing too early**. Don't box inside structs unless you are sure it'll be beneficial or is required (recursive).
135```rust
136// ✅ Use generics when possible
137struct Renderer<B: Backend> {
138    backend: B
139}
140 
141// ❌ Premature Boxing
142struct Renderer {
143    backend: Box<dyn Backend> // Boxing too early
144}
145```
146* If you must expose a `dyn trait` in a public API, `Box` at the boundary, not internally.
147* **Object Safety**: You can only create `dyn Traits` from object-safe traits:
148    * It has **no generic methods**.
149    * It doesn't require `Self: Sized`.
150    * All method signatures use `&self`, `&mut self` or `self`.
151    ```rust
152    // ✅ Object Safe
153    trait Runnable {
154        fn run(&self);
155    }
156 
157    // ❌ Not Object Safe
158    trait Factory {
159        fn create<T>() -> T; // generic methods are not allowed
160    }
161    ```
162