Generics and trait bounds

Why generics?

Imagine writing largest_i32, largest_f64 and largest_char: three functions with the same logic and different types. Generics remove this duplication. A generic is a placeholder for a type, written in angle brackets, usually named T (for "type"). You have already used generics: Vec<T>, Option<T>, Result<T, E> and HashMap<K, V>.

fn largest<T: PartialOrd + Copy>(list: &[T]) -> T {
    let mut big = list[0];
    for &item in list {
        if item > big {
            big = item;
        }
    }
    big
}

fn main() {
    println!("{}", largest(&[34, 50, 25, 100, 65]));   // 100
    println!("{}", largest(&[1.5, 0.2, 9.9]));          // 9.9
    println!("{}", largest(&['y', 'm', 'a', 'q']));     // y
}

Trait bounds: what T must be able to do

Inside largest we compare with > and copy values out. Not every type can do that. A trait bound limits T to types that implement certain traits. T: PartialOrd + Copy means "T can be compared and copied". Without the bound, the compiler says "binary operation > cannot be applied to type T" and suggests the bound.

Three ways to write bounds

// 1. inline
fn show<T: std::fmt::Display>(x: T) { println!("{x}"); }

// 2. where clause: easier to read with many bounds
fn report<T, U>(a: T, b: U) -> String
where
    T: std::fmt::Display + Clone,
    U: std::fmt::Debug,
{
    format!("{a} / {:?}", b)
}

// 3. impl Trait in argument position (short form of 1)
fn show2(x: impl std::fmt::Display) { println!("{x}"); }

Generic structs and impl blocks

#[derive(Debug)]
struct Pair<T> {
    a: T,
    b: T,
}

impl<T: PartialOrd + std::fmt::Display> Pair<T> {
    fn bigger(&self) -> &T {
        if self.a >= self.b { &self.a } else { &self.b }
    }
}

fn main() {
    let p = Pair { a: 7, b: 12 };
    println!("{}", p.bigger());     // 12
}

impl Trait in return position

fn make_counter() -> impl Iterator<Item = u32> says "I return some type that is an iterator of u32; you do not need its exact name". This is very useful for iterators and closures, whose real types are long or impossible to write. The function must still return one single concrete type.

Monomorphization: zero-cost generics

When you call largest with i32 and with f64, the compiler generates two specialised copies, largest::<i32> and largest::<f64>, as if you had written them by hand. This is called monomorphization. The result runs as fast as hand-written code. The cost is compile time and a larger program file when a generic is used with many types.

largest(&[1, 2])    -> compiler makes  fn largest_i32(list: &[i32]) -> i32
largest(&[1.0, 2.0]) -> compiler makes  fn largest_f64(list: &[f64]) -> f64

Turbofish

Sometimes the compiler cannot guess T. Then you name it with the "turbofish" syntax ::<>, which you met with parse::<u32>() and collect::<Vec<_>>().

Common mistakes

• Missing bounds: using > or {} on T without PartialOrd or Display. Add the bound the compiler suggests.
• Too many bounds "just in case". Ask only for what the function really uses.
• Returning different types from an impl Trait function (one branch a Vec iterator, another a range). It must be one concrete type; use Box<dyn Trait> for that case (next topic).
• Forgetting <T> after impl: write impl<T> Pair<T>, not impl Pair<T>.