Rust Notes: Generics

Generics in Rust

Generics are Rust’s mechanism for writing code that works with multiple types without duplicating the implementation.

Instead of writing:

fn largest_i32(list: &[i32]) -> &i32 {
    // ...
}

and another function for f64:

fn largest_f64(list: &[f64]) -> &f64 {
    // ...
}

we can write one generic function:

fn largest<T>(list: &[T]) -> &T {
    // ...
}

Here T is a generic type parameter.

Generics are one of the foundations of Rust’s type system and appear together with:

• ownership
• borrowing
• lifetimes
• traits
• trait bounds
• associated types
• impl Trait
• trait objects
• const generics
• static dispatch
• monomorphization

The most important idea is:

Generics let us write code in terms of a type that will be specified later.

---

1. Why Do We Need Generics?

Imagine we want a function that returns the first element of a slice.

Without generics:

fn first_i32(values: &[i32]) -> &i32 {
    &values[0]
}

fn first_string(values: &[String]) -> &String {
    &values[0]
}

fn first_f64(values: &[f64]) -> &f64 {
    &values[0]
}

The implementations are identical.

Only the type changes.

Generics allow us to write:

fn first<T>(values: &[T]) -> &T {
    &values[0]
}

Now the same function works with:

let numbers = vec![1, 2, 3];
let strings = vec![
    String::from("hello"),
    String::from("world"),
];

let n = first(&numbers);
let s = first(&strings);

The compiler determines T from the arguments.

---

2. What Is T?

In:

fn first<T>(values: &[T]) -> &T {
    &values[0]
}

T is a type parameter.

Think of it as a placeholder:

T
│
└── some type

For example, when calling:

first(&numbers)

the compiler can infer:

T = i32

When calling:

first(&strings)

it can infer:

T = String

Conceptually:

first<i32>(&[i32])
first<String>(&[String])

---

3. Generic Syntax

The basic syntax is:

<T>

For example:

fn foo<T>(value: T) {
}

Multiple type parameters:

fn foo<T, U>(x: T, y: U) {
}

A generic struct:

struct Pair<T, U> {
    first: T,
    second: U,
}

A generic enum:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

A generic trait:

trait Container<T> {
}

---

4. Generic Functions

The most common syntax is:

fn identity<T>(value: T) -> T {
    value
}

Usage:

let x = identity(10);
let y = identity("hello");

The compiler infers:

T = i32

for the first call and:

T = &str

for the second.

---

5. Explicit Generic Arguments

Sometimes you can specify the generic type explicitly.

For example:

fn identity<T>(value: T) -> T {
    value
}

You can write:

let x = identity::<i32>(10);

The syntax:

::<T>

is called turbofish syntax.

For multiple types:

fn pair<T, U>(x: T, y: U) -> (T, U) {
    (x, y)
}

let value = pair::<i32, String>(10, String::from("hello"));

---

6. Why Is It Called Turbofish?

This:

::<T>

is commonly called the turbofish.

For example:

foo::<i32>();

The :: followed by <...> makes the syntax visually resemble a fish.

You will frequently see it with generic methods and functions:

"42".parse::<i32>();

Here:

parse::<i32>()
       ↑
       explicitly choose T = i32

---

7. Type Inference

Rust usually does not require explicit generic arguments.

For example:

fn identity<T>(value: T) -> T {
    value
}

let x = identity(10);

Rust sees:

10 → i32

and therefore infers:

T = i32

You can explicitly specify it:

let x = identity::<i32>(10);

Both are valid.

Idiomatic Rust generally relies on inference when it is obvious.

---

8. Generic Structs

A struct can have generic type parameters:

struct Point<T> {
    x: T,
    y: T,
}

Now:

let integer_point = Point {
    x: 10,
    y: 20,
};

let float_point = Point {
    x: 1.5,
    y: 2.5,
};

Conceptually:

Point<i32>
Point<f64>

---

9. Different Types in the Same Struct

You can use multiple generic parameters:

struct Point<T, U> {
    x: T,
    y: U,
}

Now:

let point = Point {
    x: 10,
    y: 3.14,
};

Conceptually:

Point<i32, f64>

This is useful when the fields do not need to have the same type.

---

10. Generic Enums

Rust’s standard library uses generics extensively.

For example:

enum Option<T> {
    Some(T),
    None,
}

This allows:

Option<i32>
Option<String>
Option<&str>

For example:

let x: Option<i32> = Some(10);

let y: Option<String> = Some(String::from("hello"));

The enum itself does not need separate implementations for every type.

---

11. Result<T, E>

Another important generic type is:

Result<T, E>

It represents:

T → success value
E → error value

For example:

Result<String, std::io::Error>

or:

Result<i32, ParseIntError>

This is a powerful example of why generics are useful.

The same Result abstraction works with many combinations of success and error types.

---

12. Generic Methods

A struct can be generic and its methods can also be generic.

For example:

struct Container<T> {
    value: T,
}

impl<T> Container<T> {
    fn value(&self) -> &T {
        &self.value
    }
}

Notice:

impl<T> Container<T>

The first T declares the generic parameter.

The second T uses it.

---

13. Why Do We Need impl<T>?

Suppose:

struct Container<T> {
    value: T,
}

To implement methods for all T:

impl<T> Container<T> {
    fn value(&self) -> &T {
        &self.value
    }
}

Read it as:

For every type T, implement these methods for Container<T>.

---

14. Implementing Only for One Concrete Type

You can also specialize the implementation for one concrete type:

struct Container<T> {
    value: T,
}

impl Container<i32> {
    fn double(&self) -> i32 {
        self.value * 2
    }
}

Now double() exists only for:

Container<i32>

It does not exist for:

Container<String>

---

15. Generic Implementation with a Different Type Parameter

You can introduce additional generic parameters inside impl.

For example:

struct Container<T> {
    value: T,
}

impl<T> Container<T> {
    fn pair<U>(self, other: U) -> (T, U) {
        (self.value, other)
    }
}

Usage:

let c = Container { value: 10 };

let result = c.pair("hello");

The types are:

T = i32
U = &str

---

16. Generic Functions and Generic Methods Are Different

Consider:

struct Container<T> {
    value: T,
}

impl<T> Container<T> {
    fn get(&self) -> &T {
        &self.value
    }

    fn convert<U>(self, value: U) -> (T, U) {
        (self.value, value)
    }
}

Here:

T

belongs to the struct.

While:

U

belongs only to the method.

---

17. Generic Traits

Traits can also be generic:

trait Converter<T> {
    fn convert(&self) -> T;
}

A type can implement the trait for a particular T:

struct Number;

impl Converter<i32> for Number {
    fn convert(&self) -> i32 {
        42
    }
}

---

18. Trait Generic Parameters vs Associated Types

This is an important Rust distinction.

A generic trait:

trait Iterator<T> {
    fn next(&mut self) -> Option<T>;
}

would allow one type to implement the trait multiple times for different T.

Rust’s actual Iterator uses an associated type:

trait Iterator {
    type Item;

    fn next(&mut self) -> Option<Self::Item>;
}

This means a particular implementation chooses one Item type.

For example:

impl Iterator for MyIterator {
    type Item = i32;

    fn next(&mut self) -> Option<Self::Item> {
        // ...
    }
}

---

19. Why Associated Types Matter

With:

trait Iterator {
    type Item;
}

we can write:

fn sum<I>(iter: I) -> i32
where
    I: Iterator<Item = i32>,
{
    // ...
}

The Item = i32 syntax constrains the associated type.

This is different from:

I: Iterator<i32>

because Iterator does not have a generic parameter.

---

20. Trait Bounds

A generic type can have restrictions.

For example:

fn print<T: std::fmt::Display>(value: T) {
    println!("{value}");
}

The:

T: Display

is a trait bound.

It says:

T must implement Display.

Without this bound, Rust cannot assume that T supports {value} formatting.

---

21. Why Do Generic Types Need Bounds?

Consider:

fn add<T>(a: T, b: T) -> T {
    a + b
}

This does not compile.

Why?

Because Rust cannot assume that every type supports:

+

For example:

String
File
TcpStream
MyCustomType

do not automatically have addition semantics.

We need to specify the required capability.

---

22. Using a Trait Bound

For a type that supports addition:

use std::ops::Add;

fn add<T>(a: T, b: T) -> T
where
    T: Add<Output = T>,
{
    a + b
}

Now the compiler knows that T implements Add.

This demonstrates an important idea:

Generics describe what can vary; trait bounds describe what the generic type must be able to do.

---

23. Multiple Trait Bounds

You can require multiple traits:

fn process<T>(value: T)
where
    T: Clone + std::fmt::Debug + Send,
{
}

This means T must implement:

Clone
Debug
Send

You can also write:

fn process<T: Clone + std::fmt::Debug + Send>(value: T) {
}

Both forms are valid.

---

24. where Clauses

When bounds become complicated, use where:

fn process<T, U>(x: T, y: U)
where
    T: Clone + Send,
    U: std::fmt::Debug,
{
}

This is often more readable than:

fn process<T: Clone + Send, U: std::fmt::Debug>(
    x: T,
    y: U,
) {
}

A good rule:

Use inline bounds for simple constraints and where for complex ones.

---

25. Bounds on Structs

You can put bounds directly on a struct declaration:

struct Container<T>
where
    T: Clone,
{
    value: T,
}

However, it is often better to put bounds on the specific impl or function that needs them.

For example:

struct Container<T> {
    value: T,
}

impl<T> Container<T>
where
    T: Clone,
{
    fn duplicate(&self) -> T {
        self.value.clone()
    }
}

This keeps the struct usable with any T.

---

26. Bounds on impl

Very common:

impl<T> Container<T>
where
    T: Clone,
{
    fn duplicate(&self) -> T {
        self.value.clone()
    }
}

The implementation exists only for T types that implement Clone.

---

27. Conditional Methods

You can use trait bounds to make methods available only when required.

struct Container<T> {
    value: T,
}

impl<T> Container<T> {
    fn value(&self) -> &T {
        &self.value
    }
}

impl<T> Container<T>
where
    T: Clone,
{
    fn clone_value(&self) -> T {
        self.value.clone()
    }
}

Therefore:

Container<T>
    │
    ├── value()
    │
    └── clone_value()
          ↑
          only if T: Clone

---

28. Generic Trait Implementations

You can implement a trait for every type satisfying a bound:

trait Describe {
    fn describe(&self);
}

impl<T> Describe for T
where
    T: std::fmt::Debug,
{
    fn describe(&self) {
        println!("{self:?}");
    }
}

This is a blanket implementation.

It says:

Every T that implements Debug also gets this Describe implementation.

---

29. Blanket Implementations

The general syntax is:

impl<T> Trait for T
where
    T: SomeBound,
{
}

For example:

impl<T> MyTrait for T
where
    T: Clone,
{
}

This can be extremely powerful.

It is also subject to Rust’s orphan rules, which prevent arbitrary implementations of foreign traits for foreign types.

---

30. The Orphan Rule

Suppose both are defined in another crate:

Trait
Type

You cannot arbitrarily write:

impl ForeignTrait for ForeignType {
}

This restriction prevents conflicting implementations across crates.

Generally, you need to own at least one of:

trait
type

This is part of Rust’s coherence rules.

---

31. Generic Type Parameters Can Be Lifetimes Too

Generics and lifetimes can appear together.

For example:

struct Container<'a, T> {
    value: &'a T,
}

Here:

'a → lifetime parameter
T  → type parameter

You can also have multiple lifetimes:

struct Pair<'a, 'b, T> {
    first: &'a T,
    second: &'b T,
}

---

32. Lifetime Bounds on Generic Types

You can write:

fn process<'a, T>(value: &'a T)
where
    T: 'a,
{
}

Here:

T: 'a

means T is valid for at least lifetime 'a.

This matters when T itself could contain references.

---

33. Generic Functions with Lifetimes

Example:

fn first<'a, T>(items: &'a [T]) -> &'a T {
    &items[0]
}

Here:

'a → lifetime
T  → type

The returned reference is tied to the input slice.

---

34. Generic Struct + Lifetime + Trait Bound

You can combine everything:

struct Container<'a, T>
where
    T: Clone,
{
    value: &'a T,
}

You can also put the bound on the implementation instead:

struct Container<'a, T> {
    value: &'a T,
}

impl<'a, T> Container<'a, T>
where
    T: Clone,
{
    fn clone_value(&self) -> T {
        self.value.clone()
    }
}

This demonstrates how Rust’s generic system combines:

lifetimes
+
types
+
traits
+
bounds

---

35. impl Trait

Rust provides another generic-looking syntax:

fn create() -> impl Iterator<Item = i32> {
    0..10
}

impl Trait means:

The function returns some concrete type that implements this trait.

The caller does not need to know the concrete type.

---

36. impl Trait in Function Arguments

You can write:

fn print(value: impl std::fmt::Display) {
    println!("{value}");
}

This is roughly equivalent to:

fn print<T: std::fmt::Display>(value: T) {
    println!("{value}");
}

Both use static dispatch.

However, the syntax and type-system behavior are not identical in every context.

---

37. impl Trait in Return Position

Example:

fn numbers() -> impl Iterator<Item = i32> {
    0..10
}

This hides the concrete iterator type.

The caller only knows:

Iterator<Item = i32>

The compiler still knows the exact concrete type.

This is important:

impl Trait is not the same as dyn Trait.

---

38. impl Trait vs dyn Trait

Compare:

fn foo() -> impl Trait

with:

fn foo() -> Box<dyn Trait>

impl Trait generally uses static dispatch.

impl Trait
    ↓
compiler knows concrete type
    ↓
static dispatch

dyn Trait uses dynamic dispatch:

dyn Trait
    ↓
trait object
    ↓
vtable
    ↓
dynamic dispatch

---

39. Generic Function = Static Dispatch

Consider:

fn print<T: std::fmt::Display>(value: T) {
    println!("{value}");
}

When called with:

print(10);
print(3.14);

the compiler can generate specialized versions conceptually like:

print::<i32>
print::<f64>

This is called monomorphization.

---

40. Monomorphization

Rust generics normally use monomorphization.

Suppose:

fn print<T: Display>(value: T) {
    println!("{value}");
}

and:

print(10);
print(20.0);

The compiler can generate specialized machine-code versions:

print<i32>
print<f64>

Conceptually:

generic source
     │
     ▼
monomorphization
     │
     ├── T = i32
     └── T = f64

This is one reason generic Rust code can be both type-safe and fast.

---

41. Generic Code Is Not Necessarily Runtime Generic

When you write:

fn foo<T>(value: T) {
}

you might imagine one runtime function that somehow handles every possible type.

That is not generally how Rust implements it.

Rust normally specializes generic code during compilation.

Therefore the runtime usually operates on concrete machine-code versions.

---

42. Static Dispatch

With:

fn process<T: Trait>(value: T) {
}

the compiler knows the concrete type.

The call can therefore be statically dispatched.

Conceptually:

process::<TypeA>()
        ↓
known at compile time

process::<TypeB>()
        ↓
known at compile time

Advantages include:

• optimization opportunities
• no vtable lookup
• no dynamic dispatch overhead
• easier inlining

The tradeoff is potentially larger binaries due to multiple monomorphized copies.

---

43. Dynamic Dispatch

With:

fn process(value: &dyn Trait) {
}

the concrete type is not known by the function body.

Instead Rust uses a trait object and a vtable.

Conceptually:

&dyn Trait
    │
    ├── pointer to data
    │
    └── pointer to vtable
              │
              ├── method A
              ├── method B
              └── ...

The method is selected at runtime.

---

44. Generic vs Trait Object

Generic:

fn process<T: Trait>(value: T) {
}

Trait object:

fn process(value: &dyn Trait) {
}

Generic:

compile time
static dispatch
monomorphization

Trait object:

runtime
dynamic dispatch
vtable

---

45. Generic Collections

A normal Vec<T> contains one concrete type:

let values: Vec<i32> = vec![1, 2, 3];

You cannot do:

let values = vec![
    1,
    "hello",
    3.14,
];

because a Vec<T> has one T.

If you need different types, you need an abstraction such as:

enum Value {
    Integer(i32),
    Float(f64),
    Text(String),
}

or trait objects:

Vec<Box<dyn Trait>>

This distinction is important:

Generics do not mean “a collection can contain arbitrary types.”

They mean:

A generic abstraction can be instantiated with different concrete types.

---

46. Generic Type vs Trait Object

Compare:

Vec<Box<dyn Display>>

with:

Vec<T>

Vec<T>:

one concrete T

Vec<Box<dyn Display>>:

different concrete types
        ↓
all implement Display
        ↓
trait objects

This is a major difference between static and dynamic polymorphism.

---

47. Generic Associated Types

Rust also supports generic associated types (GATs).

For example:

trait Iterable {
    type Item<'a>
    where
        Self: 'a;

    fn item(&self) -> Self::Item<'_>;
}

Here:

Item<'a>

is an associated type that itself has a lifetime parameter.

GATs are particularly useful for abstractions involving borrowing.

---

48. Generic Associated Types with Types

Associated types can also have type parameters in supported contexts.

Conceptually:

trait Factory {
    type Output<T>;
}

The associated type itself becomes parameterized.

GATs are especially common when building advanced iterators, parsers, and borrowing abstractions.

---

49. Const Generics

Generics are not limited to types.

Rust also supports const generics.

Example:

struct Array<T, const N: usize> {
    data: [T; N],
}

Here:

T → type parameter
N → const parameter

Usage:

let a: Array<i32, 10>;
let b: Array<f64, 20>;

Conceptually:

Array<i32, 10>
Array<f64, 20>

---

50. Why Const Generics Are Useful

Before const generics, expressing an array type with a generic length was much more difficult.

Now we can write:

fn sum<const N: usize>(values: [i32; N]) -> i32 {
    values.iter().sum()
}

The same function works with:

sum([1, 2, 3]);
sum([1, 2, 3, 4, 5]);

The array length becomes part of the type.

---

51. Const Generic Syntax

The basic syntax is:

<const N: usize>

For example:

fn foo<const N: usize>() {
}

Multiple const parameters:

fn foo<const N: usize, const M: usize>() {
}

Combined with types:

fn foo<T, const N: usize>(value: [T; N]) {
}

---

52. Const Generic Expressions

You may encounter expressions involving const parameters:

struct Buffer<T, const N: usize> {
    data: [T; N],
}

The exact set of allowed generic const expressions depends on Rust’s current const-generic capabilities.

Simple uses such as array lengths are common and stable.

---

53. Generic Parameters Can Include Lifetimes, Types, and Consts

A generic declaration can contain all three:

struct Buffer<'a, T, const N: usize> {
    data: &'a [T; N],
}

Here:

'a → lifetime parameter
T  → type parameter
N  → const parameter

This is the complete conceptual family:

Generic parameters
├── lifetimes
├── types
└── const values

---

54. Parameter Ordering

A common generic declaration is:

struct Foo<'a, T, const N: usize> {
}

Generally, Rust syntax places:

lifetimes
    ↓
type parameters
    ↓
const parameters

For example:

fn foo<'a, T, U, const N: usize>(
    value: &'a [T; N],
    other: U,
) {
}

---

55. Generic Type Defaults

Generic parameters can have default types in certain declarations.

For example:

struct Container<T = String> {
    value: T,
}

Then:

let value = Container {
    value: String::from("hello"),
};

can use the default type when inference or context permits.

Defaults are more commonly encountered in library APIs and standard-library types.

---

56. Default Generic Type Parameters

A well-known example is:

struct Point<T = i32> {
    x: T,
    y: T,
}

Then:

Point {
    x: 10,
    y: 20,
}

can use:

T = i32

by default.

But:

Point::<f64> {
    x: 1.0,
    y: 2.0,
}

can explicitly choose another type.

---

57. Generic Type Parameters in enum

Example:

enum Either<A, B> {
    Left(A),
    Right(B),
}

Usage:

let a: Either<i32, String> = Either::Left(10);

let b: Either<i32, String> =
    Either::Right(String::from("hello"));

The two variants can carry different types.

---

58. Generic Functions with Multiple Type Parameters

Example:

fn make_pair<T, U>(first: T, second: U) -> (T, U) {
    (first, second)
}

Usage:

let pair = make_pair(10, "hello");

The compiler infers:

T = i32
U = &str

---

59. Generic Bounds Between Multiple Types

You can constrain relationships between generic types.

For example:

fn compare<T, U>(a: T, b: U)
where
    T: PartialEq<U>,
{
    println!("{}", a == b);
}

This says:

T can be compared with U

The generic relationship is not necessarily:

T == U

Instead:

T: PartialEq<U>

means T knows how to compare itself with U.

---

60. Associated Type Constraints

You can constrain an associated type:

fn sum<I>(iter: I) -> i32
where
    I: Iterator<Item = i32>,
{
    iter.sum()
}

Here:

I: Iterator

is the trait bound.

And:

Item = i32

constrains the associated type.

---

61. Fully Qualified Syntax

Generics become especially interesting when traits have associated functions or methods.

For example:

trait Animal {
    fn name() -> &'static str;
}

struct Dog;

impl Animal for Dog {
    fn name() -> &'static str {
        "Dog"
    }
}

You can call:

Dog::name();

or use fully qualified syntax:

<Type as Trait>::method()

For example:

<DOG as Animal>::name()

This syntax is useful when multiple traits provide methods with the same name.

---

62. Generic Type Syntax with Paths

Generic arguments can appear in type paths:

Vec<i32>
Option<String>
Result<T, E>
Box<dyn Trait>
Arc<T>

Nested generics:

Vec<Option<String>>

More complex:

HashMap<String, Vec<i32>>

---

63. Nested Generic Types

Generics compose naturally.

For example:

Vec<Option<Result<String, Error>>>

Read from the inside out:

String
    ↓
Result<String, Error>
    ↓
Option<Result<String, Error>>
    ↓
Vec<Option<Result<String, Error>>>

This is one of the reasons generic abstractions are powerful.

---

64. Generic Type Parameters and Ownership

A generic parameter can represent an owned value:

fn take<T>(value: T) {
}

When called:

let s = String::from("hello");

take(s);

ownership of s moves into T.

The generic parameter does not change Rust’s ownership rules.

It simply allows the function to work with different concrete types.

---

65. Generic References

You can borrow a generic type:

fn inspect<T>(value: &T) {
}

This means:

&T

for any T.

With a lifetime:

fn inspect<'a, T>(value: &'a T) {
}

Now:

'a → reference lifetime
T  → referenced type

---

66. Generic Mutable References

You can also write:

fn modify<T>(value: &mut T) {
}

Or explicitly:

fn modify<'a, T>(value: &'a mut T) {
}

Again:

'a → lifetime
T  → type

---

67. Generic Ownership vs Borrowing

Compare:

fn consume<T>(value: T) {
}

with:

fn borrow<T>(value: &T) {
}

The first takes ownership:

caller
  │
  └── moves value
          ↓
       function

The second borrows:

caller
  │
  └── owns value
       │
       └── temporary reference
                ↓
             function

Generics do not change this behavior.

---

68. Generic Trait Bounds and Ownership

You can combine ownership and trait bounds:

fn process<T>(value: T)
where
    T: Send + Sync + 'static,
{
}

This is common in concurrent Rust.

The generic parameter T is constrained by several properties.

---

69. Send and Sync as Generic Bounds

For example:

fn spawn<T>(value: T)
where
    T: Send + 'static,
{
    // ...
}

This expresses:

T can be transferred to another thread
+
T does not contain short-lived borrowed references

This is why generic APIs can encode concurrency requirements directly into the type system.

---

70. Sized

One important implicit bound is:

T: Sized

By default, generic type parameters are assumed to be Sized.

Conceptually:

fn foo<T>(value: T) {
}

means approximately:

fn foo<T: Sized>(value: T) {
}

unless you explicitly opt out.

---

71. ?Sized

To allow dynamically sized types, use:

T: ?Sized

Example:

fn print<T: ?Sized + std::fmt::Display>(value: &T) {
    println!("{value}");
}

?Sized means:

T does not have to be Sized.

This allows types such as:

str
dyn Trait

which are dynamically sized types.

---

72. Why str Needs ?Sized

str is a dynamically sized type.

You cannot normally have:

let x: str;

But you can have:

let x: &str;

A generic function taking &T can therefore be written:

fn foo<T: ?Sized>(value: &T) {
}

Now T can be:

Sized type
or
unsized type

---

73. Sized and ?Sized

Remember:

T

implicitly means:

T: Sized

while:

T: ?Sized

means:

T may or may not be Sized

This is particularly important for:

str
dyn Trait
[T]

---

74. Trait Bounds with ?Sized

You can combine them:

fn foo<T: ?Sized + Trait>(value: &T) {
}

or:

fn foo<T>(value: &T)
where
    T: ?Sized + Trait,
{
}

---

75. impl Trait and ?Sized

You will often encounter:

&impl Trait

or:

Box<dyn Trait>

The important distinction remains:

generic type parameter
    ↓
T

opaque return/argument type
    ↓
impl Trait

trait object
    ↓
dyn Trait

---

76. Generic Closures

Closures themselves have compiler-generated anonymous types.

For example:

let add = |a: i32, b: i32| a + b;

The closure has a unique compiler-generated type.

You usually interact with it through traits such as:

Fn
FnMut
FnOnce

A generic function can accept a closure:

fn apply<F>(f: F)
where
    F: Fn(i32) -> i32,
{
    println!("{}", f(10));
}

---

77. Generic Functions Accepting Closures

Example:

fn apply<F>(function: F, value: i32) -> i32
where
    F: Fn(i32) -> i32,
{
    function(value)
}

Usage:

let result = apply(|x| x * 2, 10);

Here:

F
│
└── closure type

The compiler knows the concrete closure type.

Therefore this is normally statically dispatched.

---

78. Higher-Ranked Trait Bounds

Advanced generic code may use:

for<'a>

For example:

F: for<'a> Fn(&'a str) -> &'a str

This means:

For every lifetime 'a, F can accept a &'a str and return a &'a str.

This is useful when writing generic code over borrowing closures and functions.

---

79. Generic Associated Types

GAT syntax can look like:

trait Iterable {
    type Item<'a>
    where
        Self: 'a;

    fn item(&self) -> Self::Item<'_>;
}

This combines:

associated types
+
generic parameters
+
lifetimes

GATs are especially useful for APIs that return values borrowing from self.

---

80. Generic Trait Objects

Trait objects can contain generic associated types and associated type constraints where supported.

For example:

Box<dyn Iterator<Item = i32>>

Here:

Iterator
    ↓
associated type Item
    ↓
Item = i32

The trait object itself hides the concrete iterator type.

---

81. Generic Return Types

A function can return a generic type:

fn make<T>(value: T) -> T {
    value
}

The caller determines T.

But a function cannot normally say:

fn make<T>() -> T {
    // ...
}

without having some way to determine or construct the required T.

For example:

fn make<T: Default>() -> T {
    T::default()
}

Now the trait bound gives the function a way to create T.

---

82. Generic Associated Functions

A type can have a generic associated function:

struct Factory;

impl Factory {
    fn create<T: Default>() -> T {
        T::default()
    }
}

Usage:

let x: i32 = Factory::create();

or:

let x = Factory::create::<i32>();

---

83. Generic Methods with Turbofish

For:

impl Factory {
    fn create<T: Default>() -> T {
        T::default()
    }
}

you can write:

Factory::create::<i32>()

The ::<i32> specifies the generic parameter.

---

84. Generic Constructors

Rust does not have constructors as a special language feature.

But you can create generic constructor-like associated functions:

struct Container<T> {
    value: T,
}

impl<T> Container<T> {
    fn new(value: T) -> Self {
        Self { value }
    }
}

Usage:

let x = Container::new(10);
let y = Container::new(String::from("hello"));

---

85. Self with Generics

Inside an implementation:

impl<T> Container<T> {
    fn new(value: T) -> Self {
        Self { value }
    }
}

Self means:

Container<T>

So:

fn new(value: T) -> Self

is effectively:

fn new(value: T) -> Container<T>

---

86. Generic Type Aliases

You can define:

type Pair<T> = (T, T);

Then:

let point: Pair<i32> = (10, 20);

You can combine this with lifetimes:

type StrRef<'a> = &'a str;

Or const generics:

type Array<T, const N: usize> = [T; N];

---

87. Generic Newtype Pattern

You can wrap a type:

struct Wrapper<T>(T);

Usage:

let x = Wrapper(10);
let y = Wrapper(String::from("hello"));

Conceptually:

Wrapper<i32>
Wrapper<String>

Newtypes are useful for:

• type safety
• encapsulation
• implementing traits
• distinguishing otherwise identical types

---

88. Generic Recursive Types

You can create recursive generic structures:

enum List<T> {
    Cons(T, Box<List<T>>),
    Nil,
}

Now:

List<i32>
List<String>

are possible.

The Box is necessary because recursive types need a known size.

---

89. Generics and Box

Consider:

Box<T>

Box is itself generic.

Conceptually:

Box<T>
  │
  ├── Box<i32>
  ├── Box<String>
  └── Box<MyType>

The same abstraction works with many types.

---

90. Generics and Vec

Likewise:

Vec<T>

is generic.

Examples:

Vec<i32>
Vec<String>
Vec<MyStruct>
Vec<Box<dyn Trait>>

The vector stores one concrete T.

---

91. Generic APIs in the Standard Library

Rust’s standard library is full of generics:

Option<T>
Result<T, E>
Vec<T>
Box<T>
Rc<T>
Arc<T>
Cell<T>
RefCell<T>
Mutex<T>
RwLock<T>
HashMap<K, V>
HashSet<T>

Understanding generics is therefore essential for reading Rust code.

---

92. Generics and RefCell

For example:

RefCell<T>

works for any T.

let value = RefCell::new(10);
let text = RefCell::new(String::from("hello"));

Conceptually:

RefCell<i32>
RefCell<String>

The borrowing behavior is implemented once, generically.

---

93. Generics and Arc

Similarly:

Arc<T>

can contain many types:

Arc<String>
Arc<Vec<u8>>
Arc<MyStruct>

The Arc implementation does not need to be rewritten for each type.

---

94. Generics and Smart Pointers

A useful mental model:

Box<T>
Rc<T>
Arc<T>
Cell<T>
RefCell<T>
Mutex<T>
RwLock<T>

all follow the pattern:

Wrapper<T>

where T represents the value being wrapped.

This is one of the most common uses of generics in Rust.

---

95. Generic Trait Bounds Define Capabilities

Consider:

fn save<T>(value: T)
where
    T: Serialize + Send + Sync,
{
}

The generic parameter says:

T can vary

The bounds say:

T must have these capabilities

This is a useful way to think about Rust generics:

Generic
    ↓
what can vary

Trait bound
    ↓
what must be possible

---

96. Generics and Polymorphism

Rust supports polymorphism primarily through:

Parametric polymorphism

Generics:

fn foo<T>(value: T) {}

Ad-hoc polymorphism

Traits:

trait Foo {
}

Dynamic polymorphism

Trait objects:

dyn Foo

These mechanisms solve different problems.

---

97. Generic Polymorphism

For:

fn print<T: Display>(value: T) {
    println!("{value}");
}

the same source code works with many types.

This is parametric polymorphism constrained by a trait.

For example:

T = i32
T = f64
T = String

as long as each type implements Display.

---

98. Generics vs Inheritance

Rust does not use class inheritance for generic reuse.

Instead, Rust commonly combines:

generics
+
traits
+
composition

For example:

fn process<T: Storage>(storage: T) {
}

The function does not care which concrete storage implementation it receives.

This provides polymorphism without requiring an inheritance hierarchy.

---

99. Generics and Composition

Instead of:

BaseClass
   ↑
DerivedClass
   ↑
MoreDerivedClass

Rust commonly uses:

struct Service<S> {
    storage: S,
}

with:

trait Storage {
}

Then:

Service<FileStorage>
Service<DatabaseStorage>
Service<MemoryStorage>

This is a powerful design pattern in Rust.

---

100. Generic Dependency Injection

A common pattern is:

trait Storage {
    fn get(&self, key: &str);
}

struct Service<S> {
    storage: S,
}

impl<S: Storage> Service<S> {
    fn new(storage: S) -> Self {
        Self { storage }
    }
}

Now:

let service = Service::new(MyStorage);

The service is generic over its storage implementation.

This gives static dispatch and compile-time checking.

---

101. Generic State Machines

Generics can encode state in the type system.

For example:

struct Connection<State> {
    state: State,
}

struct Connected;
struct Disconnected;

Then methods can be implemented only for certain states:

impl Connection<Disconnected> {
    fn connect(self) -> Connection<Connected> {
        Connection {
            state: Connected,
        }
    }
}

This allows invalid state transitions to become compile-time errors.

---

102. Phantom Types

Sometimes a generic parameter is used only at the type level.

For example:

use std::marker::PhantomData;

struct Id<T> {
    value: u64,
    _marker: PhantomData<T>,
}

Now:

struct User;
struct Device;

type UserId = Id<User>;
type DeviceId = Id<Device>;

Even though both contain a u64, the types are different:

UserId
≠
DeviceId

This is useful for type-level safety.

---

103. PhantomData and Generics

PhantomData<T> tells the compiler that a type logically involves T even though it does not physically store a T.

Example:

struct Token<T> {
    id: u64,
    _marker: PhantomData<T>,
}

The generic parameter participates in type checking without requiring an actual T field.

This can also affect:

• variance
• ownership reasoning
• auto traits
• drop checking

---

104. Generic Associated Constants

Traits and types can also have associated constants that work with generic types.

For example:

trait Limits {
    const MAX: usize;
}

A generic type can implement the trait:

impl<T> Limits for Vec<T> {
    const MAX: usize = 1024;
}

The implementation applies to every Vec<T>.

---

105. Generic Drop

You can implement Drop for a generic type:

struct Container<T> {
    value: T,
}

impl<T> Drop for Container<T> {
    fn drop(&mut self) {
        println!("dropping");
    }
}

The implementation applies to every Container<T>.

---

106. Generic Trait Bounds on Associated Types

You can combine bounds:

fn process<I>(iter: I)
where
    I: Iterator,
    I::Item: std::fmt::Debug,
{
    // ...
}

Here:

I implements Iterator
+
I::Item implements Debug

This pattern is very common in generic Rust code.

---

107. Nested where Constraints

Complex APIs may look like:

fn process<T, U>(value: T, other: U)
where
    T: Clone + Send,
    U: Iterator,
    U::Item: std::fmt::Debug,
{
}

Read the bounds one at a time.

Do not try to understand the whole signature at once.

---

108. Generic Function with where + Lifetime

Example:

fn process<'a, T>(value: &'a T)
where
    T: 'a + std::fmt::Debug,
{
    println!("{value:?}");
}

Break it down:

'a
    ↓
lifetime

T
    ↓
generic type

T: 'a
    ↓
T is valid for 'a

T: Debug
    ↓
T supports Debug

---

109. Generic Function with Lifetime + Trait Object

You may encounter:

fn process<'a>(value: &'a dyn Trait) {
}

This means:

'a
    ↓
lifetime of the reference

dyn Trait
    ↓
trait object

Compare:

fn process<T: Trait>(value: &T)

with:

fn process(value: &dyn Trait)

The first is generic/static dispatch.

The second is dynamic dispatch.

---

110. Generic Function Returning Trait Objects

You can write:

fn create() -> Box<dyn Trait> {
    Box::new(MyType)
}

The caller does not know the concrete type.

Compare with:

fn create() -> impl Trait {
    MyType
}

Both hide the concrete return type, but they use different mechanisms.

---

111. Generic Function Returning impl Trait

Example:

fn numbers() -> impl Iterator<Item = i32> {
    0..10
}

The compiler knows the concrete type.

The caller only knows the trait interface.

This is an opaque type.

---

112. Generic Function Accepting impl Trait

Example:

fn process(value: impl Display) {
    println!("{value}");
}

This is approximately equivalent to:

fn process<T: Display>(value: T) {
    println!("{value}");
}

Use whichever syntax makes the API clearer.

---

113. Generic Type Parameter vs impl Trait

Compare:

fn foo<T: Display>(x: T) -> T

and:

fn foo(x: impl Display) -> impl Display

The first explicitly names T, so you can use the same type parameter elsewhere:

fn foo<T: Display>(x: T, y: T) -> T

With:

fn foo(x: impl Display, y: impl Display)

the two parameters may have different concrete types.

This is an important difference.

---

114. impl Trait Parameters Can Represent Different Types

For:

fn foo(x: impl Display, y: impl Display) {
}

conceptually:

x: T
y: U

T: Display
U: Display

So:

foo(10, "hello");

can work.

But:

fn foo<T: Display>(x: T, y: T) {
}

requires:

x and y have the same T

---

115. Generic Parameters Express Equality of Types

For:

fn pair<T>(x: T, y: T) -> (T, T) {
    (x, y)
}

both arguments must have the same type.

But:

fn pair(x: impl Display, y: impl Display) {
}

does not require the same type.

This makes generic syntax semantically important.

---

116. Generic Return Types Must Be Determined

Consider:

fn create<T>() -> T {
    // ?
}

The compiler cannot magically create an arbitrary T.

A trait bound can provide the necessary operation:

fn create<T: Default>() -> T {
    T::default()
}

This is a common generic design pattern.

---

117. Generic Bounds as Interfaces

A generic function:

fn save<T: Write>(value: T) {
}

does not care whether T is:

File
TcpStream
Vec<u8>
CustomWriter

It only requires:

T: Write

This is similar to programming against an interface.

But unlike inheritance-based interfaces, Rust traits are independent capabilities that types can implement.

---

118. Static Dispatch and Performance

Generic code:

fn process<T: Trait>(value: T) {
}

can often be optimized aggressively.

Because the compiler knows:

exact type
exact implementation

it can potentially:

• inline calls
• remove abstraction overhead
• specialize code
• optimize data layout

This is one of the major strengths of Rust’s generics.

---

119. The Cost of Monomorphization

Monomorphization is not free.

If a generic function is instantiated for many different types:

T = A
T = B
T = C
T = D
...

the binary may contain multiple specialized versions.

Potential consequences:

• larger binaries
• longer compilation times
• more generated machine code

This is one reason dynamic dispatch can sometimes be useful.

---

120. Generics vs Dynamic Dispatch

A useful comparison:

Feature	Generics	dyn Trait
Dispatch	Static	Dynamic
Concrete type known by compiler	Yes	No
Monomorphization	Yes	No
Vtable	No	Yes
Runtime dispatch cost	Usually none	Usually small
Binary size	Can increase	Often smaller
Heterogeneous collection	Not directly	Yes
Compile-time optimization	Strong	More limited

Neither approach is universally better.

Choose based on the API and requirements.

---

121. Generic Code and Zero-Cost Abstractions

Rust often aims for abstractions that compile down to code comparable to handwritten specialized code.

For example:

fn process<T: Trait>(value: T) {
    value.method();
}

The generic abstraction itself does not necessarily introduce runtime overhead.

The compiler can specialize it.

This is one of the reasons generics are heavily used throughout Rust’s standard library.

---

122. Generics and Type Safety

Generics prevent many classes of mistakes.

For example:

struct UserId(u64);
struct DeviceId(u64);

Even though both contain:

u64

they are different types.

Generic wrappers can extend this idea:

struct Id<T> {
    value: u64,
    _marker: PhantomData<T>,
}

Now:

Id<User>
Id<Device>

cannot accidentally be mixed.

---

123. Generics and API Design

When designing a generic API, ask:

What varies?

Use a generic parameter:

<T>

What must the type be able to do?

Use a trait bound:

T: Trait

Does the API need to return an abstract implementation?

Consider:

impl Trait

Does the API need heterogeneous values?

Consider:

dyn Trait

Does the type need to encode a number?

Consider:

const N: usize

Does the type borrow data?

Consider:

'a

---

124. Generic Syntax Cheat Sheet

One type parameter

<T>

Multiple type parameters

<T, U>

Generic function

fn foo<T>(value: T) {
}

Generic function with return type

fn foo<T>(value: T) -> T {
    value
}

Generic struct

struct Foo<T> {
    value: T,
}

Generic enum

enum Foo<T> {
    Value(T),
}

Generic trait

trait Foo<T> {
}

Generic implementation

impl<T> Foo<T> {
}

Generic trait implementation

impl<T> Trait for Foo<T> {
}

Trait bound

T: Trait

Multiple bounds

T: TraitA + TraitB

where

fn foo<T, U>(x: T, y: U)
where
    T: TraitA,
    U: TraitB,
{
}

Associated type constraint

T: Iterator<Item = i32>

impl Trait parameter

fn foo(value: impl Trait) {
}

impl Trait return

fn foo() -> impl Trait {
}

Trait object

dyn Trait

Boxed trait object

Box<dyn Trait>

Lifetime + generic type

fn foo<'a, T>(value: &'a T) {
}

Lifetime bound

T: 'a

Lifetime outlives

'a: 'b

Anonymous lifetime

'_

Higher-ranked trait bound

for<'a>

Sized

T: Sized

Allow unsized types

T: ?Sized

Const generic

<const N: usize>

Type + const generic

<T, const N: usize>

Lifetime + type + const

<'a, T, const N: usize>

Turbofish

::<T>

Multiple turbofish arguments

::<T, U>

---

125. A Complete Generic Example

Here is an example combining many of the concepts:

use std::fmt::Debug;

struct Container<'a, T, const N: usize> {
    values: &'a [T; N],
}

impl<'a, T, const N: usize> Container<'a, T, N>
where
    T: Debug,
{
    fn print(&self) {
        println!("{:?}", self.values);
    }

    fn first(&self) -> &T {
        &self.values[0]
    }
}

This contains:

'a
    lifetime parameter

T
    type parameter

N
    const parameter

T: Debug
    trait bound

&'a [T; N]
    borrowed array

impl<'a, T, const N: usize>
    generic implementation

This is a good example of how Rust’s generic system combines multiple concepts.

---

126. How to Read Complex Generic Signatures

When you see a complicated Rust signature, don’t try to understand it all at once.

For example:

fn process<'a, T, U, const N: usize>(
    value: &'a [T; N],
    other: U,
) -> &'a T
where
    T: Clone + Debug,
    U: Send + 'static,
{
    &value[0]
}

Read it in layers.

Layer 1: Lifetime

'a

There is a lifetime parameter.

Layer 2: Types

T
U

There are two type parameters.

Layer 3: Const

const N: usize

There is a compile-time integer parameter.

Layer 4: Inputs

&'a [T; N]

A reference to an array of N values of type T.

U

An owned value of type U.

Layer 5: Output

&'a T

A reference to T tied to 'a.

Layer 6: Bounds

T: Clone + Debug

T must implement Clone and Debug.

U: Send + 'static

U must satisfy Send and 'static.

This layered approach makes complex Rust signatures much easier to understand.

---

127. Generics Are Compile-Time Abstraction

A useful mental model is:

Generic source code
       │
       ▼
Compiler
       │
       ├── T = i32
       ├── T = String
       └── T = MyType
       │
       ▼
Concrete machine code

The generic abstraction exists primarily at compile time.

This is different from dynamic dispatch, where the runtime may need to determine which implementation to call.

---

128. The Three Main Generic Parameter Categories

Rust’s generic parameters can be understood as three categories:

Generic parameters
│
├── Lifetime
│     'a
│
├── Type
│     T
│
└── Const
      N

For example:

struct Buffer<'a, T, const N: usize> {
    data: &'a [T; N],
}

contains all three.

---

129. Generics, Traits, and Lifetimes Work Together

These three concepts are often learned separately, but real Rust code combines them.

For example:

fn process<'a, T>(value: &'a T)
where
    T: Clone + Send + 'a,
{
}

Here:

'a
    lifetime

T
    generic type

Clone
    capability

Send
    concurrency capability

T: 'a
    lifetime relationship

Rust’s type system allows all these constraints to be expressed together.

---

130. The Big Picture

Generics answer:

What type can vary?

Traits answer:

What behavior does that type provide?

Trait bounds answer:

What behavior must the generic type provide?

Lifetimes answer:

How long are borrowed references valid?

Const generics answer:

What compile-time value can vary?

impl Trait answers:

Can I hide the concrete type while exposing its capabilities?

dyn Trait answers:

Can I use runtime polymorphism through a trait object?

Monomorphization answers:

How can generic code become concrete machine code?

---

131. Final Mental Model

When you see:

fn process<T: Trait>(value: T)

think:

T
│
└── some concrete type
       │
       └── must implement Trait

When you see:

fn process<'a, T>(value: &'a T)

think:

'a
 │
 └── lifetime of the reference

T
 │
 └── type being referenced

When you see:

fn process<T, U>(x: T, y: U)

think:

T and U may be different types

When you see:

fn process<T>(x: T, y: T)

think:

x and y must have the same type T

When you see:

fn process(x: impl Trait)

think:

some concrete type implementing Trait

When you see:

fn process(x: &dyn Trait)

think:

trait object
+
dynamic dispatch

When you see:

T: ?Sized

think:

T may be dynamically sized

When you see:

<const N: usize>

think:

N is a compile-time value

When you see:

for<'a>

think:

for every possible lifetime 'a

And the most important idea is:

Generics allow Rust to abstract over types, lifetimes, and compile-time values while preserving strong compile-time type checking and, in the common case, enabling static dispatch and zero-cost abstractions.

---