Generic Functions

19 min read

Generic functions let you write one function that works for many types, without giving up type safety. If you have ever written function first<T>(arr: T[]): T in TypeScript, you already know the shape of the idea — but Rust compiles generics in a fundamentally different way, and that difference has real consequences for performance, error messages, and what you can and cannot do at runtime.

Quick Overview

A generic function is parameterized over one or more types written in angle brackets (fn name<T>(...)). The same source produces a separate, specialized machine-code copy for each concrete type it is used with — a process called monomorphization. This is the opposite of TypeScript, where generics are erased before the code ever runs, so a TS dev’s main adjustment is realizing that in Rust generics are a compile-time mechanism with zero runtime cost, not a runtime feature.

TypeScript/JavaScript Example

1
// TypeScript - generic functions with type parameters
2
function first<T>(items: T[]): T {
3
  return items[0];
4
}
5

6
function pair<A, B>(a: A, b: B): [A, B] {
7
  return [a, b];
8
}
9

10
// The type parameter is inferred from the arguments...
11
const n = first([10, 20, 30]); // T = number, n: number
12
const s = first(["a", "b"]); // T = string, s: string
13
const p = pair(1, "one"); // A = number, B = string
14

15
// ...or supplied explicitly with the same angle-bracket syntax:
16
const x = first<number>([1, 2, 3]);
17

18
// At RUNTIME, T is gone. This compiles and runs — and crashes:
19
function bad<T>(items: T[]): T {
20
  return items[0];
21
}
22
console.log(bad<number>([])); // undefined — no error, types were erased

Key points:

<T> declares a type parameter; TypeScript infers it from arguments.
Generics are a compile-time-only check. tsc erases them and emits plain JavaScript — there is no T left at runtime.
Because the types are gone, you cannot inspect T, branch on it, or new T(). And mistakes the types should have caught (like indexing an empty array) still produce undefined at runtime.

Rust Equivalent

1
// Rust - the same two functions, with type parameters in <>
2
fn first<T>(items: &[T]) -> &T {
3
    &items[0]
4
}
5

6
fn pair<A, B>(a: A, b: B) -> (A, B) {
7
    (a, b)
8
}
9

10
fn main() {
11
    let nums = [10, 20, 30];
12
    let n = first(&nums); // T = i32, inferred from the argument
13
    println!("first: {n}");
14

15
    let words = ["a", "b"];
16
    let s = first(&words); // T = &str, inferred
17
    println!("first: {s}");
18

19
    let p = pair(1, "one"); // A = i32, B = &str
20
    println!("pair: {p:?}"); // prints: pair: (1, "one")
21
}

Real output from cargo run:

1
first: 10
2
first: a
3
pair: (1, "one")

Key points:

The syntax is strikingly similar: fn first<T>(...).
Rust infers T from arguments just like TypeScript.
But unlike TypeScript, first(&nums) and first(&words) cause the compiler to generate two distinct copies of first — one specialized for i32, one for &str. The generic is resolved entirely at compile time, then erased into concrete, optimized code.

Note: Rust borrows the slice (&[T]) instead of taking ownership of an array. We will not dwell on borrowing here — see Section 05: Ownership — but notice first returns &T (a reference), so it does not have to copy the element out.

Detailed Explanation

Declaring and inferring type parameters

1
fn first<T>(items: &[T]) -> &T {
2
    &items[0]
3
}

<T> after the function name introduces the type parameter. T is just a name; U, Item, or Value work equally well, though single uppercase letters are the convention for “any type.”
Inside the body, T stands for whatever concrete type the caller uses. You may use T in the parameter list (&[T]), the return type (&T), and local bindings.
At the call site first(&nums), Rust unifies &[T] with &[i32; 3] (coerced to &[i32]) and concludes T = i32. No annotation needed.

Monomorphization: the big mental shift from TypeScript

This is the single most important idea for a TS/JS developer. TypeScript erases generics; Rust monomorphizes them. When you call a generic function with i32 and with f64, the compiler stamps out two separate functions, each with the concrete type baked in — exactly as if you had hand-written id_i32 and id_f64.

We can prove it. Compiling this program to LLVM IR:

1
use std::hint::black_box;
2

3
#[inline(never)]
4
pub fn id<T>(x: T) -> T {
5
    x
6
}
7

8
fn main() {
9
    let a = id::<i32>(black_box(5));
10
    let b = id::<f64>(black_box(2.5));
11
    println!("{} {}", black_box(a), black_box(b));
12
}

…produces two distinct, fully concrete definitions of id in the emitted IR — one taking an i32, one taking a double (Rust’s f64):

1
define internal i32    @_ZN4mono2id17h73ef7d59100e96ddE(i32 %x) ...
2
define internal double @_ZN4mono2id17h901c7050e1366328E(double %x) ...

Note: Those two define lines are real output from rustc --emit=llvm-ir. The i32 copy and the double (f64) copy are genuinely separate machine functions generated from one generic source.

The consequences for a TypeScript developer:

Aspect	TypeScript (erasure)	Rust (monomorphization)
When is `T` resolved?	Compile time, then erased	Compile time, then specialized into concrete code
Runtime representation of `T`	None — it does not exist	None needed — every copy is concrete
Runtime cost of generics	The code is just plain JS	Zero — as fast as hand-written concrete code
Can you inspect `T` at runtime?	No (`typeof` sees the value, not `T`)	No (and you rarely need to)
Effect on binary/output size	None (one copy)	Larger binary — one copy per type used (“code bloat”)
Compile time	Fast	Slower — more code to generate and optimize

The headline win is zero-cost abstraction: a generic first<T> is exactly as fast as a first_i32 you wrote by hand, because after monomorphization that is literally what exists. The trade-off is binary size and compile time, since each instantiation is real code.

Inferred vs explicit type arguments — the turbofish `::<>`

Most of the time Rust infers the type parameter. When it cannot — or when you want to be explicit — you supply the type argument. In an expression, that uses the turbofish syntax ::<>:

1
fn largest<T: PartialOrd + Copy>(list: &[T]) -> T {
2
    let mut max = list[0];
3
    for &item in list {
4
        if item > max {
5
            max = item;
6
        }
7
    }
8
    max
9
}
10

11
fn main() {
12
    // Inferred from the argument:
13
    let m = largest(&[3, 9, 1]);
14
    println!("{m}");
15

16
    // Explicit, using the turbofish on the function name:
17
    let m = largest::<i32>(&[3, 9, 1]);
18
    println!("{m}");
19
}

The name “turbofish” comes from the ::<> glyph resembling a fish. Why the leading ::? Because largest<i32>(...) would be ambiguous to the parser — < could be the less-than operator. The :: disambiguates “this is a type argument list,” not a comparison.

You will see the turbofish most often on standard-library methods whose return type the compiler cannot otherwise pin down:

1
fn main() {
2
    // `parse` is generic over its return type; tell it what to produce:
3
    let n = "42".parse::<i32>().unwrap();
4
    println!("{n}"); // 42
5

6
    // `collect` builds "some collection" — turbofish picks which one:
7
    let v = (0..3).collect::<Vec<i32>>();
8
    println!("{v:?}"); // [0, 1, 2]
9
}

Equivalently, you can move the type to the binding and let inference flow backward — these two lines are interchangeable:

1
fn main() {
2
    let v = (0..3).collect::<Vec<i32>>(); // turbofish on the method
3
    let v: Vec<i32> = (0..3).collect();   // annotation on the variable
4
    println!("{v:?}");
5
}

This “type flows backward from the annotation” behavior has no real TypeScript analog — in TS you almost always write [...] and the array type is concrete already.

Generic functions usually need trait bounds

In TypeScript a bare <T> is fully usable: you can pass it around, put it in arrays, return it. In Rust a bare <T> is deliberately almost useless — you can move it, return it, or store it, but you cannot do anything that requires a capability, because the compiler must guarantee the operation works for every possible T. Comparing with >, adding with +, or printing with {} are all capabilities you must request via trait bounds (T: PartialOrd, T: Display, …). That is why largest above is written largest<T: PartialOrd + Copy> rather than just largest<T>. Trait bounds are a topic of their own — see trait-bounds.md — but you cannot write many generic functions without at least one, so they appear here too.

Key Differences

Concept	TypeScript	Rust
Declaration	`function f<T>(x: T): T`	`fn f<T>(x: T) -> T`
Inference	Yes, from arguments	Yes, from arguments
Explicit type arg	`f<number>(x)`	`f::<i32>(x)` (turbofish in expressions)
Compilation model	Erasure — one runtime copy	Monomorphization — one copy per concrete type
Runtime cost	None (it is just JS)	Zero (specialized to concrete code)
Capabilities on `T`	Anything; unsound casts via `any` slip through	Only what trait bounds permit; checked
”Empty” bound `<T>`	Fully usable	Can only move/store/return — no operations
Inspect `T` at runtime	No	No (use enums/trait objects for runtime polymorphism)
Binary size impact	None	Grows with number of instantiations

The conceptual core: TypeScript generics are a type-checker feature that disappears; Rust generics are a code-generation feature. Rust trades larger binaries and slower compiles for code that is as fast as if you had never used generics at all — and for the guarantee that every operation on T is provably valid for every T you actually use.

Tip: Reach for generics when you want one implementation specialized per type at compile time (the common case). When you instead need runtime polymorphism — a heterogeneous list of “things that implement Draw,” chosen at runtime — that is trait objects (dyn Trait), Rust’s dynamic-dispatch counterpart.

Common Pitfalls

Pitfall 1: Forgetting a trait bound when you operate on `T`

A TypeScript dev expects T to “just work” with > or +. Rust refuses, because it cannot prove those operations are valid for every T.

1
// does not compile (error E0369: binary operation `>` cannot be applied to type `T`)
2
fn largest<T>(list: &[T]) -> T {
3
    let mut max = list[0];
4
    for &item in list {
5
        if item > max {
6
            max = item;
7
        }
8
    }
9
    max
10
}

Real compiler output:

1
error[E0369]: binary operation `>` cannot be applied to type `T`
2
 --> err1.rs:4:17
3
  |
4
4 |         if item > max {
5
  |            ---- ^ --- T
6
  |            |
7
  |            T
8
  |
9
help: consider restricting type parameter `T` with trait `PartialOrd`
10
  |
11
1 | fn largest<T: std::cmp::PartialOrd>(list: &[T]) -> T {
12
  |             ++++++++++++++++++++++

The compiler even writes the fix for you: add T: PartialOrd. (For comparing-and-copying scalars like i32, you typically also want + Copy, as in the working version above.)

The same thing happens with +:

1
// does not compile (error E0369: cannot add `T` to `T`)
2
fn add<T>(a: T, b: T) -> T {
3
    a + b
4
}

1
error[E0369]: cannot add `T` to `T`
2
 --> err4.rs:2:7
3
  |
4
2 |     a + b
5
  |     - ^ - T
6
  |     |
7
  |     T
8
  |
9
help: consider restricting type parameter `T` with trait `Add`
10
  |
11
1 | fn add<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
12
  |         +++++++++++++++++++++++++++

Pitfall 2: Ambiguous return type — the compiler needs a turbofish or annotation

parse and collect are generic over what they produce. With nothing to pin the result type, inference fails:

1
// does not compile (error E0284: type annotations needed)
2
fn main() {
3
    let n = "42".parse().unwrap();
4
    println!("{n}");
5
}

1
error[E0284]: type annotations needed
2
 --> err2.rs:2:9
3
  |
4
2 |     let n = "42".parse().unwrap();
5
  |         ^        ----- type must be known at this point
6
  |
7
  = note: cannot satisfy `<_ as FromStr>::Err == _`
8
help: consider giving `n` an explicit type
9
  |
10
2 |     let n: /* Type */ = "42".parse().unwrap();
11
  |          ++++++++++++

Fix it with the turbofish ("42".parse::<i32>()) or a binding annotation (let n: i32 = ...). collect gives the analogous E0283:

1
error[E0283]: type annotations needed
2
    --> err3.rs:2:9
3
     |
4
   2 |     let v = (0..5).collect();
5
     |         ^          ------- type must be known at this point
6
     |
7
     = note: cannot satisfy `_: FromIterator<i32>`
8
note: required by a bound in `collect`
9
    --> .../library/core/src/iter/traits/iterator.rs:2014:19
10
     |
11
2014 |     fn collect<B: FromIterator<Self::Item>>(self) -> B
12
     |                   ^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `Iterator::collect`
13
help: consider giving `v` an explicit type
14
     |
15
   2 |     let v: Vec<_> = (0..5).collect();
16
     |          ++++++++

Pitfall 3: Expecting to inspect or branch on `T` at runtime

Because generics are monomorphized and then erased into concrete code, there is no runtime “type object” to look at. There is no typeof T, no if (T === Number), no new T(). If you need to make a runtime decision based on the variant, that is a job for an enum or a trait object, not for generics. This mirrors TypeScript’s erasure (you cannot do if (T === ...) in TS either) — but TS devs sometimes think they can via instanceof on values, which checks the runtime value, not the erased type parameter.

Pitfall 4: Assuming generics are “free” like in TypeScript

In TypeScript a generic costs nothing at runtime and nothing in output size — it is the same emitted JS. In Rust, every distinct type you instantiate a generic with generates another copy of the code. Calling largest with i32, f64, char, and u8 produces four specialized functions. This is usually a non-issue, but for very large generic functions used with many types it can bloat the binary and slow compiles. When that matters, you can extract the type-independent work into a non-generic inner function (a technique sometimes called “outlining”).

Best Practices

Let inference do the work. Write let n = parse_count(input); and only add a turbofish or annotation when the compiler asks. Over-annotating reads as noise.
Add the minimum bounds you need, no more. Each bound is a promise the caller must keep. T: PartialOrd is weaker (more permissible) than T: Ord; pick the loosest one that compiles. See trait-bounds.md.
Name type parameters meaningfully when it aids clarity. T is fine for a one-off, but fn group_by<T, K, F>(...) reading “item, key, function” is clearer than <A, B, C>.
Prefer borrowing generic inputs (&[T], &T) over taking ownership when you only need to read, so callers are not forced to give up their data.
Reach for impl Trait in argument position for simple “accept any iterator / any closure” cases; it is a lighter-weight sugar over a generic parameter. See impl-trait.md.
Use generics for compile-time, same-shape-per-type code; use dyn Trait for runtime, heterogeneous collections. Knowing which axis you are on prevents fighting the borrow checker later.

Tip: When you find yourself writing the same function body twice for i32 and f64, that is the signal to make it generic. When you find yourself wanting a Vec holding several different concrete types at once, that is the signal you want a trait object instead.

Real-World Example

A small data-pipeline module: two reusable, fully generic helpers — group_by (bucket items by a derived key) and max_by_key (find the “biggest” item by a derived score). Both are parameterized over the element type and a closure, so they work for any data the caller throws at them. This is the kind of generic utility you would otherwise reach for Lodash to provide in TypeScript.

1
use std::collections::HashMap;
2
use std::hash::Hash;
3

4
/// Group items into buckets keyed by a value derived from each item.
5
fn group_by<T, K, F>(items: Vec<T>, key_of: F) -> HashMap<K, Vec<T>>
6
where
7
    K: Eq + Hash,
8
    F: Fn(&T) -> K,
9
{
10
    let mut groups: HashMap<K, Vec<T>> = HashMap::new();
11
    for item in items {
12
        let key = key_of(&item);
13
        groups.entry(key).or_default().push(item);
14
    }
15
    groups
16
}
17

18
/// Return the item with the largest derived key, or `None` if empty.
19
fn max_by_key<T, K, F>(items: &[T], key_of: F) -> Option<&T>
20
where
21
    K: PartialOrd,
22
    F: Fn(&T) -> K,
23
{
24
    let mut best: Option<&T> = None;
25
    let mut best_key: Option<K> = None;
26
    for item in items {
27
        let k = key_of(item);
28
        match &best_key {
29
            Some(bk) if !(k > *bk) => {}
30
            _ => {
31
                best = Some(item);
32
                best_key = Some(k);
33
            }
34
        }
35
    }
36
    best
37
}
38

39
#[derive(Debug)]
40
struct Order {
41
    id: u32,
42
    customer: &'static str,
43
    total: f64,
44
}
45

46
fn main() {
47
    let orders = vec![
48
        Order { id: 1, customer: "ada", total: 42.0 },
49
        Order { id: 2, customer: "linus", total: 99.5 },
50
        Order { id: 3, customer: "ada", total: 10.0 },
51
    ];
52

53
    // `max_by_key` is inferred: T = Order, K = f64, F = the closure
54
    let biggest = max_by_key(&orders, |o| o.total);
55
    println!("biggest order: {:?}", biggest.map(|o| o.id));
56

57
    // `group_by` consumes the Vec and buckets by customer name
58
    let by_customer = group_by(orders, |o| o.customer);
59
    let mut customers: Vec<_> = by_customer.keys().copied().collect();
60
    customers.sort();
61
    for c in customers {
62
        println!("{c}: {} orders", by_customer[c].len());
63
    }
64
}

Real output from cargo run:

1
biggest order: Some(2)
2
ada: 2 orders
3
linus: 1 orders

Notice that all three type parameters of each function are inferred — no turbofish needed at the call sites — because the Vec<Order> and the closures fully determine T, K, and F. The standard library’s own Iterator::max_by_key is built on exactly this pattern; here we wrote our own to see the mechanics.

Note: F: Fn(&T) -> K is a trait bound on a closure type — closures in Rust each have a unique, unnameable type, so you accept them via a generic parameter bounded by the Fn family. The standard HashMap used here is covered in Section 07: Collections.

Exercises

Exercise 1: Swap a pair

Difficulty: Beginner

Objective: Get comfortable declaring multiple type parameters and returning a generic tuple.

Instructions: Write a generic function swap that takes a tuple (A, B) and returns it with the elements swapped, as (B, A). It should require no trait bounds. Verify that swap((1, "a")) returns ("a", 1).

1
fn swap<A, B>(pair: (A, B)) -> (B, A) {
2
    // TODO: destructure and return swapped
3
    todo!()
4
}
5

6
fn main() {
7
    let result = swap((1, "a"));
8
    println!("{result:?}"); // ("a", 1)
9
}

Solution

1
fn swap<A, B>(pair: (A, B)) -> (B, A) {
2
    let (a, b) = pair;
3
    (b, a)
4
}
5

6
fn main() {
7
    let result = swap((1, "a"));
8
    println!("{result:?}"); // ("a", 1)
9
    assert_eq!(swap((1, "a")), ("a", 1));
10
}

No trait bounds are needed: we only move the values, never operate on them, so the empty <A, B> is enough. This is one of the rare cases where a bound-free generic is genuinely useful.

Exercise 2: Print any two displayable values

Difficulty: Intermediate

Objective: Apply trait bounds so the function body can actually use the type parameters, and observe the compiler error if you forget them.

Instructions: Write a generic function print_pair<T, U>(a: T, b: U) that prints a and b in the form "<a> and <b>". To use {} formatting on a and b, you must bound both parameters with std::fmt::Display. First try it without the bounds and read the error; then add them.

1
fn print_pair<T, U>(a: T, b: U) {
2
    // TODO: add the necessary bounds in the signature, then:
3
    println!("{a} and {b}");
4
}
5

6
fn main() {
7
    print_pair(1, "one");
8
    print_pair(3.14, 'x');
9
}

Solution

1
use std::fmt::Display;
2

3
fn print_pair<T: Display, U: Display>(a: T, b: U) {
4
    println!("{a} and {b}");
5
}
6

7
fn main() {
8
    print_pair(1, "one");   // 1 and one
9
    print_pair(3.14, 'x');  // 3.14 and x
10
}

Without the Display bounds, the compiler rejects the {} formatting with error[E0277]: T doesn't implement std::fmt::Display. The bound is the promise “every type passed here can be displayed,” which the compiler then enforces at each call site.

Exercise 3: Count matching elements with a predicate closure

Difficulty: Advanced

Objective: Combine a generic element type with a generic closure parameter, using a where clause.

Instructions: Write count_matching<T, F>(items: &[T], pred: F) -> usize that returns how many elements satisfy the predicate pred. The closure parameter F must be bounded by Fn(&T) -> bool. Use a where clause for readability. Verify that counting the even numbers in [1, 2, 3, 4] yields 2.

1
fn count_matching<T, F>(items: &[T], pred: F) -> usize
2
where
3
    // TODO: bound F so it can be called as `pred(&item) -> bool`
4
{
5
    // TODO: count the matches (an iterator chain works well)
6
    todo!()
7
}
8

9
fn main() {
10
    let evens = count_matching(&[1, 2, 3, 4], |&n| n % 2 == 0);
11
    println!("evens: {evens}"); // 2
12
}

Solution

1
fn count_matching<T, F>(items: &[T], pred: F) -> usize
2
where
3
    F: Fn(&T) -> bool,
4
{
5
    items.iter().filter(|x| pred(x)).count()
6
}
7

8
fn main() {
9
    let evens = count_matching(&[1, 2, 3, 4], |&n| n % 2 == 0);
10
    println!("evens: {evens}"); // 2
11
    assert_eq!(count_matching(&[1, 2, 3, 4], |&n| n % 2 == 0), 2);
12

13
    // Works for any element type, because T is generic:
14
    let words = ["hi", "hello", "yo"];
15
    assert_eq!(count_matching(&words, |s| s.len() > 2), 1); // only "hello"
16
}

F: Fn(&T) -> bool lets the function accept any closure (or function pointer) that takes a &T and returns a bool. Because the closure has a unique, unnameable type, accepting it through a generic parameter is the idiomatic way — see Section 03: Functions for closures and impl Trait for the lighter-weight pred: impl Fn(&T) -> bool spelling of the same thing.

Generic Functions

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Declaring and inferring type parameters

Monomorphization: the big mental shift from TypeScript

Inferred vs explicit type arguments — the turbofish ::<>

Generic functions usually need trait bounds

Key Differences

Common Pitfalls

Pitfall 1: Forgetting a trait bound when you operate on T

Pitfall 2: Ambiguous return type — the compiler needs a turbofish or annotation

Pitfall 3: Expecting to inspect or branch on T at runtime

Pitfall 4: Assuming generics are “free” like in TypeScript

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Swap a pair

Exercise 2: Print any two displayable values

Exercise 3: Count matching elements with a predicate closure

Inferred vs explicit type arguments — the turbofish `::<>`

Pitfall 1: Forgetting a trait bound when you operate on `T`

Pitfall 3: Expecting to inspect or branch on `T` at runtime