Generic Associated Types (GATs)

22 min read

Generic associated types let an associated type inside a trait take its own generic parameters — most importantly a lifetime. Stabilized in Rust 1.65 (November 2022) after roughly six years of design work, they unlock patterns that the trait system simply could not express before, the canonical one being the lending iterator: an iterator whose items borrow from the iterator itself.

Quick Overview

A normal associated type is a single fixed type per implementation: Iterator has type Item;, and once you pick Item = String, every call to next yields the same String type. A generic associated type adds parameters to that associated type, so the concrete type can depend on, for example, a lifetime: type Item<'a>;. Now next can hand back something that borrows from &mut self and is only valid until the next call.

For a TypeScript/JavaScript developer the closest mental hook is a generic type member inside an interface — but the analogy is loose. TypeScript has no lifetimes at all, so the entire problem GATs solve (returning a borrow tied to self) does not exist in TS; the language sidesteps it by garbage-collecting and copying. The value of GATs is precisely in the place TypeScript has nothing to say: expressing, in the type system, that a returned reference may not outlive the call that produced it.

TypeScript/JavaScript Example

Consider an iterator that yields overlapping windows of an array. In TypeScript you would reach for a generator, and each window is a brand-new array produced by .slice():

1
// A reusable "windows" iterator over an array that yields views.
2
// In JS/TS there is no borrowing: every yielded slice is a fresh array (a copy).
3
function* windows<T>(arr: readonly T[], size: number): Generator<T[]> {
4
  for (let i = 0; i + size <= arr.length; i++) {
5
    yield arr.slice(i, i + size); // .slice() ALLOCATES a new array each time
6
  }
7
}
8

9
const data = [1, 2, 3, 4, 5];
10
for (const w of windows(data, 3)) {
11
  const sum = w.reduce((a, b) => a + b, 0);
12
  console.log(`window ${JSON.stringify(w)} sum = ${sum}`);
13
}

Running it with Node v22 (node --experimental-strip-types):

1
window [1,2,3] sum = 6
2
window [2,3,4] sum = 9
3
window [3,4,5] sum = 12

This works fine, but notice what it costs and what it hides:

It allocates. Every yield arr.slice(...) builds a new heap array. For three windows over five elements that is three throwaway arrays.
There is no concept of “valid only until the next step”. Each yielded array is an independent, garbage-collected object that lives as long as anything references it. The runtime never tracks that a window is a view into shared data, because in JavaScript it is not — it is a copy.

In Rust we want the opposite: each window should be a borrowed slice into the underlying data, with zero allocation, and the type system should enforce that you do not keep one window alive while advancing to the next. Expressing “the item borrows from the iterator” is exactly what requires a GAT.

Rust Equivalent

Here is the lending iterator trait and a Windows implementation. The associated type Item<'a> carries a lifetime — that is the generic associated type:

1
// A "lending" iterator: each item may borrow from the iterator itself.
2
// The associated type `Item<'a>` is generic over a lifetime — that is the GAT.
3
trait LendingIterator {
4
    type Item<'a>
5
    where
6
        Self: 'a;
7

8
    fn next(&mut self) -> Option<Self::Item<'_>>;
9
}
10

11
// Yields overlapping windows of a slice, reusing one internal cursor.
12
struct Windows<'data, T> {
13
    slice: &'data [T],
14
    size: usize,
15
    pos: usize,
16
}
17

18
impl<'data, T> Windows<'data, T> {
19
    fn new(slice: &'data [T], size: usize) -> Self {
20
        Windows { slice, size, pos: 0 }
21
    }
22
}
23

24
impl<'data, T> LendingIterator for Windows<'data, T> {
25
    // Each yielded window borrows from `self` for the duration `'a`.
26
    type Item<'a>
27
        = &'a [T]
28
    where
29
        Self: 'a;
30

31
    fn next(&mut self) -> Option<Self::Item<'_>> {
32
        if self.pos + self.size > self.slice.len() {
33
            return None;
34
        }
35
        let window = &self.slice[self.pos..self.pos + self.size];
36
        self.pos += 1;
37
        Some(window)
38
    }
39
}
40

41
fn main() {
42
    let data = [1, 2, 3, 4, 5];
43
    let mut windows = Windows::new(&data, 3);
44

45
    // We must use a `while let` loop, not `for`: each borrow ends before the
46
    // next `next()` call, which is exactly the constraint a GAT encodes.
47
    while let Some(window) = windows.next() {
48
        let sum: i32 = window.iter().sum();
49
        println!("window {window:?} sum = {sum}");
50
    }
51
}

Real output:

1
window [1, 2, 3] sum = 6
2
window [2, 3, 4] sum = 9
3
window [3, 4, 5] sum = 12

Same results as TypeScript, but every window is a &[i32] pointing straight into data — no allocation, no copy. The 'a on Item<'a> is what lets next return a reference whose lifetime is tied to the &mut self borrow, and the borrow checker enforces that you finish with one window before asking for the next.

Detailed Explanation

The signature `fn next(&mut self) -> Option<Self::Item<'_>>`

The '_ here is the elided lifetime of the &mut self borrow. Written in full it is:

1
// The fully-spelled-out signature; '_ above is shorthand for this 'a.
2
fn next<'a>(&'a mut self) -> Option<Self::Item<'a>> { /* ... */ }

So each call says: “I am borrowing self for 'a, and the item I return is valid for exactly that 'a.” When the returned window goes out of scope, the borrow of self ends, and only then can you call next again. This is the entire trick. The item’s lifetime is plumbed through the associated type, which is impossible unless the associated type itself can take a lifetime parameter.

Why the standard `Iterator` cannot do this

The standard library’s Iterator looks like this (simplified):

1
trait Iterator {
2
    type Item;                                  // NO lifetime parameter
3
    fn next(&mut self) -> Option<Self::Item>;
4
}

Item is a single fixed type with no way to mention the lifetime of the &mut self borrow. So if you try to make Item a borrow that points into self, there is nowhere to attach the lifetime, and the compiler rejects it. This is the historical reason a “streaming”/lending iterator was impossible before GATs — and the compiler’s own diagnostic now says so out loud:

1
// does not compile: std Iterator's Item cannot borrow from self.
2
struct WindowsStd<'data, T> {
3
    slice: &'data [T],
4
    size: usize,
5
    pos: usize,
6
}
7

8
impl<'data, T> Iterator for WindowsStd<'data, T> {
9
    type Item = &[T]; // error: missing lifetime — Item can't borrow from self
10
    fn next(&mut self) -> Option<Self::Item> {
11
        None
12
    }
13
}

The real error:

1
error: associated type `Iterator::Item` is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
2
  --> src/main.rs:11:17
3
   |
4
11 |     type Item = &[T]; // missing lifetime; std Item can't borrow from self
5
   |                 ^
6
   |
7
note: you can't create an `Iterator` that borrows each `Item` from itself, but you can instead create a new type that borrows your existing type and implement `Iterator` for that new type

The diagnostic literally explains the limitation: “you can’t create an Iterator that borrows each Item from itself.” GATs are the feature that lifts this restriction — by moving the lifetime onto the associated type.

Note: std::slice::windows does exist and yields &[T], but it is not a lending iterator. Each &[T] it returns borrows from the original slice, not from the iterator’s internal state, so all the windows can coexist. A lending iterator is the harder case where items borrow from self, which is why it needs a GAT.

The mandatory `where Self: 'a` bound

Every GAT in these examples carries where Self: 'a:

1
type Item<'a>
2
where
3
    Self: 'a;

This bound reads: “Item<'a> is only meaningful for lifetimes 'a during which Self itself is valid.” It prevents you from constructing an Item<'a> that outlives the very value it borrows from. The compiler currently requires this bound (it is part of how GATs were stabilized soundly), and it tells you exactly what to add if you forget — see Common Pitfalls.

`while let`, not `for`

The loop is while let Some(window) = windows.next(), not for window in windows. The for loop desugars to the standard Iterator, which a lending iterator cannot implement (its items borrow from self). With a lending iterator you drive it manually, and the while let shape is ideal: each window lives only inside one loop iteration, so its borrow of windows ends before the next next() call. This is not a wart — it is the borrow rule made visible.

Why this was “hard”: six years of design

GATs were first proposed in RFC 1598 in 2016 and did not stabilize until Rust 1.65 in late 2022. The difficulty was never the surface syntax; it was making the feature sound and the type checker able to reason about it. Among the hard problems: deciding which where-clause bounds must be required (hence the forced where Self: 'a), how GATs interact with higher-ranked trait bounds, lifetime variance, and how implied bounds flow through. Several of those interactions are still being smoothed out (the closure friction below is one), which is why the stabilization announcement called it a minimum viable version.

GATs over types, not just lifetimes

A GAT can be generic over a type too, not only a lifetime. This expresses type families — a single trait that maps an input type to an output container type:

1
use std::rc::Rc;
2
use std::sync::Arc;
3

4
// A GAT can be generic over a TYPE too. Here, a "smart pointer family":
5
// given a family, `Of<T>` is the concrete pointer type wrapping a T.
6
trait PointerFamily {
7
    type Of<T>;
8
    fn new<T>(value: T) -> Self::Of<T>;
9
}
10

11
struct RcFamily;
12
struct ArcFamily;
13

14
impl PointerFamily for RcFamily {
15
    type Of<T> = Rc<T>;
16
    fn new<T>(value: T) -> Rc<T> {
17
        Rc::new(value)
18
    }
19
}
20

21
impl PointerFamily for ArcFamily {
22
    type Of<T> = Arc<T>;
23
    fn new<T>(value: T) -> Arc<T> {
24
        Arc::new(value)
25
    }
26
}
27

28
// Generic over the family: this code does not know whether it is single- or
29
// multi-threaded refcounting; it just asks the family for the pointer type.
30
fn boxed_pair<F: PointerFamily>(a: i32, b: i32) -> (F::Of<i32>, F::Of<i32>) {
31
    (F::new(a), F::new(b))
32
}
33

34
fn main() {
35
    let (x, y) = boxed_pair::<RcFamily>(1, 2);
36
    println!("Rc:  {x} {y}");
37
    let (p, q) = boxed_pair::<ArcFamily>(3, 4);
38
    println!("Arc: {p} {q}");
39
}

Real output:

1
Rc:  1 2
2
Arc: 3 4

boxed_pair is written once and is generic over the pointer family: pass RcFamily for single-threaded reference counting (Rc) or ArcFamily for the atomic, thread-safe variant — without the function ever naming Rc or Arc. This “higher-kinded-types-lite” pattern is the second major thing GATs enable.

Key Differences

Aspect	TypeScript / JavaScript	Rust GATs
Concept exists?	No lifetimes, so “item borrows from iterator” is a non-problem	The core problem GATs solve
How “windows” are yielded	Fresh `.slice()` copy each step (allocates, GC-managed)	Borrowed `&[T]` view into the data (zero allocation)
Two items alive at once	Always allowed (independent copies)	Rejected by the borrow checker for a lending iterator
Iteration syntax	`for (const x of it)`	`while let Some(x) = it.next()` (no `for`)
Associated type members	An interface can declare a generic member type	An associated type can take lifetime and type parameters
Runtime cost	Per-item allocation	None; items are references

The standard `Iterator` did not gain GATs

A reasonable assumption is that Iterator was rewritten to use a GAT once they stabilized. It was not — doing so would break the entire ecosystem and the for-loop desugaring. The lending iterator lives as a separate concept (the lending-iterator crate on crates.io packages it for reuse). GATs are additive: they let new traits express borrowing items; they did not retrofit the old one.

A still-rough edge: GATs and closures

GATs are stable and sound, but a few ergonomic interactions remain unsolved. The sharpest one a TS/JS developer is likely to hit: writing a generic combinator that passes each borrowed item to a closure often fails to type-check when the iterator borrows from a local (non-'static) value. The compiler over-constrains the closure’s input lifetime to 'static:

1
// A generic `for_each` over a lending iterator, taking a closure.
2
fn for_each<L, F>(mut iter: L, mut f: F)
3
where
4
    L: LendingIterator,
5
    F: FnMut(L::Item<'_>),   // <- the trouble spot
6
{
7
    while let Some(item) = iter.next() {
8
        f(item);
9
    }
10
}

Used with an iterator that borrows a local array, the real error is:

1
error[E0597]: `data` does not live long enough
2
  --> src/main.rs:45:36
3
   |
4
44 |     let data = [1, 2, 3, 4];
5
   |         ---- binding `data` declared here
6
45 |     let windows = Windows { slice: &data, size: 2, pos: 0 };
7
   |                                    ^^^^^ borrowed value does not live long enough
8
...
9
   = argument requires that `data` is borrowed for `'static`
10
   |
11
note: due to current limitations in the borrow checker, this implies a `'static` lifetime

The phrase “due to current limitations in the borrow checker” is the compiler admitting this is a known incompleteness, not your mistake. The practical takeaways: prefer a plain while let loop at the call site, or keep combinators as default methods on the trait (where Self::Item<'_> resolves against the concrete Self) and have them consume items rather than route them through a returning closure. The Best Practices section shows the patterns that do work.

Common Pitfalls

Pitfall 1: Forgetting `where Self: 'a`

The most common first error. Declare the GAT without its required bound:

1
trait LendingIterator {
2
    type Item<'a>; // does not compile: missing `where Self: 'a`
3
    fn next(&mut self) -> Option<Self::Item<'_>>;
4
}

The real compiler error tells you precisely what to add:

1
error: missing required bound on `Item`
2
 --> src/main.rs:2:5
3
  |
4
2 |     type Item<'a>; // missing `where Self: 'a`
5
  |     ^^^^^^^^^^^^^-
6
  |                  |
7
  |                  help: add the required where clause: `where Self: 'a`
8
  |
9
  = note: this bound is currently required to ensure that impls have maximum flexibility
10
  = note: we are soliciting feedback, see issue #87479 <https://github.com/rust-lang/rust/issues/87479> for more information

The fix is a literal copy-paste of the help: line. The bound guarantees an Item<'a> can never outlive the Self it borrows from.

Pitfall 2: Trying to hold two lent items at once

Because each item borrows &mut self, you cannot keep one alive while taking the next — and that surprises developers used to JavaScript’s independent array copies:

1
fn main() {
2
    let data = [1, 2, 3, 4, 5];
3
    let mut windows = Windows { slice: &data, size: 2, pos: 0 };
4

5
    let first = windows.next().unwrap();  // borrows windows mutably
6
    let second = windows.next().unwrap(); // does not compile
7
    println!("{first:?} {second:?}");
8
}

The real error:

1
error[E0499]: cannot borrow `windows` as mutable more than once at a time
2
  --> src/main.rs:31:18
3
   |
4
30 |     let first = windows.next().unwrap();  // borrows windows mutably
5
   |                 ------- first mutable borrow occurs here
6
31 |     let second = windows.next().unwrap(); // second mutable borrow while `first` is live
7
   |                  ^^^^^^^ second mutable borrow occurs here
8
32 |     println!("{first:?} {second:?}");
9
   |                ----- first borrow later used here

This is not a GAT-specific error — it is the ordinary borrow rule from Section 05: Borrowing. But it is the defining feature of a lending iterator: the type signature deliberately makes “collect all the items into a Vec and keep them” impossible, because the items are transient views. If you need them all at once, map each to an owned value first.

Pitfall 3: Expecting `for` to work

1
for window in windows { /* ... */ } // does not compile

for requires std::iter::Iterator, which a lending iterator deliberately does not implement (it cannot — see the Detailed Explanation). Use while let Some(item) = it.next(). There is no way around this for genuinely lending iterators, and that is by design.

Pitfall 4: Trying to make a `dyn LendingIterator`

A trait containing a GAT is not dyn-compatible (formerly “object-safe”), so you cannot build a trait object out of it:

1
// does not compile: a trait with a GAT is not dyn-compatible.
2
fn take(_it: &dyn LendingIterator) {}

The real error:

1
error[E0038]: the trait `LendingIterator` is not dyn compatible
2
 --> src/main.rs:7:19
3
  |
4
7 | fn take(_it: &dyn LendingIterator) {}
5
  |                   ^^^^^^^^^^^^^^^ `LendingIterator` is not dyn compatible
6
  |
7
note: for a trait to be dyn compatible it needs to allow building a vtable
8
 --> src/main.rs:2:10
9
  |
10
1 | trait LendingIterator {
11
  |       --------------- this trait is not dyn compatible...
12
2 |     type Item<'a> where Self: 'a;
13
  |          ^^^^ ...because it contains the generic associated type `Item`
14
  = help: consider moving `Item` to another trait

A vtable entry would need a single concrete type for Item, but a GAT is a family of types indexed by a lifetime, so there is nothing to put in the vtable. Use static dispatch (generics: fn take<L: LendingIterator>(it: L)) instead. For background on the static-vs-dynamic dispatch trade-off, see Trait Objects.

Best Practices

Reach for a GAT only when you genuinely need an associated type to borrow from self (lending/streaming iterators, cursor APIs, parsers that hand back views into a reused buffer) or to express a type family (the pointer-family pattern). For everything else, a plain associated type or a generic method is simpler. GATs add real cognitive cost; do not use them to look clever.
Always add the where Self: 'a bound on a lifetime-GAT from the start. It is required, and the compiler will demand it anyway.

Drive lending iterators with while let, and offer ergonomic helpers as default trait methods that consume items rather than free functions taking returning closures (which hit the borrow-checker limitation shown above). A consuming count is a clean example:

1
trait LendingIterator {
2
    type Item<'a>
3
    where
4
        Self: 'a;
5

6
    fn next(&mut self) -> Option<Self::Item<'_>>;
7

8
    // A default method that consumes the iterator. It never holds two items
9
    // at once, so it works even though items borrow from `self`.
10
    fn count(mut self) -> usize
11
    where
12
        Self: Sized,
13
    {
14
        let mut n = 0;
15
        while self.next().is_some() {
16
            n += 1;
17
        }
18
        n
19
    }
20
}
21

22
struct Windows<'data, T> {
23
    slice: &'data [T],
24
    size: usize,
25
    pos: usize,
26
}
27

28
impl<'data, T> Windows<'data, T> {
29
    fn new(slice: &'data [T], size: usize) -> Self {
30
        Windows { slice, size, pos: 0 }
31
    }
32
}
33

34
impl<'data, T> LendingIterator for Windows<'data, T> {
35
    type Item<'a>
36
        = &'a [T]
37
    where
38
        Self: 'a;
39

40
    fn next(&mut self) -> Option<Self::Item<'_>> {
41
        if self.pos + self.size > self.slice.len() {
42
            return None;
43
        }
44
        let window = &self.slice[self.pos..self.pos + self.size];
45
        self.pos += 1;
46
        Some(window)
47
    }
48
}
49

50
fn main() {
51
    let data = [1, 2, 3, 4, 5];
52
    println!("count = {}", Windows::new(&data, 2).count()); // 4
53
}

Real output:

1
count = 4

Prefer the lending-iterator crate over hand-rolling when you want the full set of adapters (map, filter, etc.) on streaming iterators. It works through the GAT friction so you do not have to:
```
1
# cargo add lending-iterator
2
[dependencies]
3
lending-iterator = "0.1.7"
```
Use static dispatch (generics), not dyn, for GAT traits, since they are not dyn-compatible. If you truly need dynamic dispatch, factor the GAT into a separate, non-dyn trait as the compiler’s help: suggests, or erase to owned values at the boundary.
Document the “valid until next call” contract on your next-style methods. The lifetime enforces it, but a one-line doc comment spares readers from puzzling over why they cannot stash an item.

Real-World Example

A zero-copy log scanner. We read newline-delimited records out of one in-memory buffer and hand each line back as a borrowed &str view — no per-line String allocation, unlike buffer.split('\n').collect::<Vec<_>>() or the JavaScript version that copies every slice. This is the production-grade payoff of lending iterators: high-throughput parsing with zero allocation per item.

1
// A zero-copy line reader over an in-memory buffer. Each call to `next`
2
// lends a `&str` view into the buffer; no per-line String is allocated.
3
trait LendingIterator {
4
    type Item<'a>
5
    where
6
        Self: 'a;
7

8
    fn next(&mut self) -> Option<Self::Item<'_>>;
9
}
10

11
struct Lines<'buf> {
12
    rest: &'buf str,
13
}
14

15
impl<'buf> Lines<'buf> {
16
    fn new(buf: &'buf str) -> Self {
17
        Lines { rest: buf }
18
    }
19
}
20

21
impl<'buf> LendingIterator for Lines<'buf> {
22
    type Item<'a>
23
        = &'a str
24
    where
25
        Self: 'a;
26

27
    fn next(&mut self) -> Option<Self::Item<'_>> {
28
        if self.rest.is_empty() {
29
            return None;
30
        }
31
        match self.rest.find('\n') {
32
            Some(idx) => {
33
                let line = &self.rest[..idx];
34
                self.rest = &self.rest[idx + 1..];
35
                Some(line)
36
            }
37
            None => {
38
                let line = self.rest;
39
                self.rest = "";
40
                Some(line)
41
            }
42
        }
43
    }
44
}
45

46
fn main() {
47
    let log = "GET /  200\nPOST /login  401\nGET /health  200";
48

49
    // Count 2xx responses without allocating a String for any line.
50
    let mut count_ok = 0;
51
    let mut lines = Lines::new(log);
52
    while let Some(line) = lines.next() {
53
        if line.ends_with("200") {
54
            count_ok += 1;
55
        }
56
        println!("line: {line:?}");
57
    }
58
    println!("2xx responses: {count_ok}");
59
}

Real output:

1
line: "GET /  200"
2
line: "POST /login  401"
3
line: "GET /health  200"
4
2xx responses: 2

Each line is a &str slice pointing into log; the iterator owns nothing but a cursor (rest). In a real service you would back the buffer with &mut [u8] refilled from a socket and lend &[u8] frames, processing gigabytes with a single reusable buffer — the kind of allocation discipline that matters in the contexts of Section 21: Performance and Section 26: Systems Programming.

Tip: When a borrowed &str is almost always a view but occasionally needs to be owned (say you must mutate or store it past the borrow), Cow<str> is the idiomatic bridge — see Clone-on-Write (Cow).

Exercises

Exercise 1: A mutable lending iterator

Difficulty: Beginner

Objective: Implement a lending iterator that yields mutable borrows, so the caller can edit elements in place.

Instructions: Using the LendingIterator trait from this chapter, implement IterMut<'data, T> over a &'data mut [T] whose Item<'a> is &'a mut T. Each next should yield the next element by mutable reference. Drive it with a while let loop to add 1 to every element of [10, 20, 30], then print the array (expect [11, 21, 31]).

Solution

1
trait LendingIterator {
2
    type Item<'a>
3
    where
4
        Self: 'a;
5
    fn next(&mut self) -> Option<Self::Item<'_>>;
6
}
7

8
struct IterMut<'data, T> {
9
    slice: &'data mut [T],
10
    pos: usize,
11
}
12

13
impl<'data, T> LendingIterator for IterMut<'data, T> {
14
    type Item<'a>
15
        = &'a mut T
16
    where
17
        Self: 'a;
18

19
    fn next(&mut self) -> Option<Self::Item<'_>> {
20
        let item = self.slice.get_mut(self.pos);
21
        if item.is_some() {
22
            self.pos += 1;
23
        }
24
        item
25
    }
26
}
27

28
fn main() {
29
    let mut data = [10, 20, 30];
30
    let mut it = IterMut { slice: &mut data, pos: 0 };
31
    while let Some(x) = it.next() {
32
        *x += 1;
33
    }
34
    println!("{data:?}"); // [11, 21, 31]
35
}

Exercise 2: A consuming `count` default method

Difficulty: Intermediate

Objective: Add a generic default method to the trait and exercise it on a chunking iterator.

Instructions: Add a count(self) -> usize default method to LendingIterator (consuming self, requiring Self: Sized). Implement Chunks<'data, T> over a &'data [T] whose Item<'a> is &'a [T], yielding non-overlapping chunks of a given size (use slice::split_at). Verify that chunking [1, 2, 3, 4, 5, 6, 7] by 3 yields a count of 3.

Solution

1
trait LendingIterator {
2
    type Item<'a>
3
    where
4
        Self: 'a;
5
    fn next(&mut self) -> Option<Self::Item<'_>>;
6

7
    fn count(mut self) -> usize
8
    where
9
        Self: Sized,
10
    {
11
        let mut n = 0;
12
        while self.next().is_some() {
13
            n += 1;
14
        }
15
        n
16
    }
17
}
18

19
struct Chunks<'data, T> {
20
    slice: &'data [T],
21
    size: usize,
22
}
23

24
impl<'data, T> LendingIterator for Chunks<'data, T> {
25
    type Item<'a>
26
        = &'a [T]
27
    where
28
        Self: 'a;
29

30
    fn next(&mut self) -> Option<Self::Item<'_>> {
31
        if self.slice.is_empty() {
32
            return None;
33
        }
34
        let take = self.size.min(self.slice.len());
35
        let (head, tail) = self.slice.split_at(take);
36
        self.slice = tail;
37
        Some(head)
38
    }
39
}
40

41
fn main() {
42
    let data = [1, 2, 3, 4, 5, 6, 7];
43
    let chunks = Chunks { slice: &data, size: 3 };
44
    println!("chunks = {}", chunks.count()); // 3
45
}

Exercise 3: A pointer-family GAT

Difficulty: Intermediate

Objective: Use a GAT generic over a type to abstract over single- vs multi-threaded reference counting.

Instructions: Define a PointerFamily trait with type Of<T>; and fn new<T>(value: T) -> Self::Of<T>;. Implement it for RcFamily (Of<T> = Rc<T>) and ArcFamily (Of<T> = Arc<T>). Then write a generic fn wrap<F: PointerFamily>(value: &str) -> F::Of<String> that wraps an owned String. Call it with both families and print the results (e.g. Rc("hi") and Arc("bye")).

Solution

1
use std::rc::Rc;
2
use std::sync::Arc;
3

4
trait PointerFamily {
5
    type Of<T>;
6
    fn new<T>(value: T) -> Self::Of<T>;
7
}
8

9
struct RcFamily;
10
struct ArcFamily;
11

12
impl PointerFamily for RcFamily {
13
    type Of<T> = Rc<T>;
14
    fn new<T>(value: T) -> Rc<T> {
15
        Rc::new(value)
16
    }
17
}
18

19
impl PointerFamily for ArcFamily {
20
    type Of<T> = Arc<T>;
21
    fn new<T>(value: T) -> Arc<T> {
22
        Arc::new(value)
23
    }
24
}
25

26
fn wrap<F: PointerFamily>(value: &str) -> F::Of<String> {
27
    F::new(value.to_string())
28
}
29

30
fn main() {
31
    let single = wrap::<RcFamily>("hi");
32
    let shared = wrap::<ArcFamily>("bye");
33
    println!("Rc  -> {single}");
34
    println!("Arc -> {shared}");
35
}

Real output:

1
Rc  -> hi
2
Arc -> bye

Generic Associated Types (GATs)

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

The signature fn next(&mut self) -> Option<Self::Item<'_>>

Why the standard Iterator cannot do this

The mandatory where Self: 'a bound

while let, not for

Why this was “hard”: six years of design

GATs over types, not just lifetimes

Key Differences

The standard Iterator did not gain GATs

A still-rough edge: GATs and closures

Common Pitfalls

Pitfall 1: Forgetting where Self: 'a

Pitfall 2: Trying to hold two lent items at once

Pitfall 3: Expecting for to work

Pitfall 4: Trying to make a dyn LendingIterator

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: A mutable lending iterator

Exercise 2: A consuming count default method

Exercise 3: A pointer-family GAT

The signature `fn next(&mut self) -> Option<Self::Item<'_>>`

Why the standard `Iterator` cannot do this

The mandatory `where Self: 'a` bound

`while let`, not `for`

The standard `Iterator` did not gain GATs

Pitfall 1: Forgetting `where Self: 'a`

Pitfall 3: Expecting `for` to work

Pitfall 4: Trying to make a `dyn LendingIterator`

Exercise 2: A consuming `count` default method