**1.**Introduction**2.**Getting Started**3.**Learn Rust**4.**Syntax and Semantics**4.1.**Variable Bindings**4.2.**Functions**4.3.**Primitive Types**4.4.**Comments**4.5.**if**4.6.**Loops**4.7.**Ownership**4.8.**References and Borrowing**4.9.**Lifetimes**4.10.**Mutability**4.11.**Structs**4.12.**Enums**4.13.**Match**4.14.**Patterns**4.15.**Method Syntax**4.16.**Vectors**4.17.**Strings**4.18.**Generics**4.19.**Traits**4.20.**Drop**4.21.**if let**4.22.**Trait Objects**4.23.**Closures**4.24.**Universal Function Call Syntax**4.25.**Crates and Modules**4.26.**`const` and `static`**4.27.**Attributes**4.28.**`type` aliases**4.29.**Casting between types**4.30.**Associated Types**4.31.**Unsized Types**4.32.**Operators and Overloading**4.33.**Deref coercions**4.34.**Macros**4.35.**Raw Pointers**4.36.**`unsafe`

**5.**Effective Rust**6.**Nightly Rust**7.**Glossary**8.**Syntax Index**9.**Bibliography

Associated types are a powerful part of Rust’s type system. They’re related to
the idea of a ‘type family’, in other words, grouping multiple types together. That
description is a bit abstract, so let’s dive right into an example. If you want
to write a `Graph`

trait, you have two types to be generic over: the node type
and the edge type. So you might write a trait, `Graph<N, E>`

, that looks like
this:

trait Graph<N, E> { fn has_edge(&self, &N, &N) -> bool; fn edges(&self, &N) -> Vec<E>; // etc }

While this sort of works, it ends up being awkward. For example, any function
that wants to take a `Graph`

as a parameter now *also* needs to be generic over
the `N`

ode and `E`

dge types too:

fn distance<N, E, G: Graph<N, E>>(graph: &G, start: &N, end: &N) -> u32 { ... }

Our distance calculation works regardless of our `Edge`

type, so the `E`

stuff in
this signature is just a distraction.

What we really want to say is that a certain `E`

dge and `N`

ode type come together
to form each kind of `Graph`

. We can do that with associated types:

trait Graph { type N; type E; fn has_edge(&self, &Self::N, &Self::N) -> bool; fn edges(&self, &Self::N) -> Vec<Self::E>; // etc }

Now, our clients can be abstract over a given `Graph`

:

fn distance<G: Graph>(graph: &G, start: &G::N, end: &G::N) -> u32 { ... }

No need to deal with the `E`

dge type here!

Let’s go over all this in more detail.

Let’s build that `Graph`

trait. Here’s the definition:

trait Graph { type N; type E; fn has_edge(&self, &Self::N, &Self::N) -> bool; fn edges(&self, &Self::N) -> Vec<Self::E>; }

Simple enough. Associated types use the `type`

keyword, and go inside the body
of the trait, with the functions.

These `type`

declarations can have all the same thing as functions do. For example,
if we wanted our `N`

type to implement `Display`

, so we can print the nodes out,
we could do this:

use std::fmt; trait Graph { type N: fmt::Display; type E; fn has_edge(&self, &Self::N, &Self::N) -> bool; fn edges(&self, &Self::N) -> Vec<Self::E>; }

Just like any trait, traits that use associated types use the `impl`

keyword to
provide implementations. Here’s a simple implementation of Graph:

struct Node; struct Edge; struct MyGraph; impl Graph for MyGraph { type N = Node; type E = Edge; fn has_edge(&self, n1: &Node, n2: &Node) -> bool { true } fn edges(&self, n: &Node) -> Vec<Edge> { Vec::new() } }

This silly implementation always returns `true`

and an empty `Vec<Edge>`

, but it
gives you an idea of how to implement this kind of thing. We first need three
`struct`

s, one for the graph, one for the node, and one for the edge. If it made
more sense to use a different type, that would work as well, we’re just going to
use `struct`

s for all three here.

Next is the `impl`

line, which is just like implementing any other trait.

From here, we use `=`

to define our associated types. The name the trait uses
goes on the left of the `=`

, and the concrete type we’re `impl`

ementing this
for goes on the right. Finally, we use the concrete types in our function
declarations.

There’s one more bit of syntax we should talk about: trait objects. If you try to create a trait object from an associated type, like this:

fn main() { trait Graph { type N; type E; fn has_edge(&self, &Self::N, &Self::N) -> bool; fn edges(&self, &Self::N) -> Vec<Self::E>; } struct Node; struct Edge; struct MyGraph; impl Graph for MyGraph { type N = Node; type E = Edge; fn has_edge(&self, n1: &Node, n2: &Node) -> bool { true } fn edges(&self, n: &Node) -> Vec<Edge> { Vec::new() } } let graph = MyGraph; let obj = Box::new(graph) as Box<Graph>; }let graph = MyGraph; let obj = Box::new(graph) as Box<Graph>;

You’ll get two errors:

```
error: the value of the associated type `E` (from the trait `main::Graph`) must
be specified [E0191]
let obj = Box::new(graph) as Box<Graph>;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
24:44 error: the value of the associated type `N` (from the trait
`main::Graph`) must be specified [E0191]
let obj = Box::new(graph) as Box<Graph>;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

We can’t create a trait object like this, because we don’t know the associated types. Instead, we can write this:

fn main() { trait Graph { type N; type E; fn has_edge(&self, &Self::N, &Self::N) -> bool; fn edges(&self, &Self::N) -> Vec<Self::E>; } struct Node; struct Edge; struct MyGraph; impl Graph for MyGraph { type N = Node; type E = Edge; fn has_edge(&self, n1: &Node, n2: &Node) -> bool { true } fn edges(&self, n: &Node) -> Vec<Edge> { Vec::new() } } let graph = MyGraph; let obj = Box::new(graph) as Box<Graph<N=Node, E=Edge>>; }let graph = MyGraph; let obj = Box::new(graph) as Box<Graph<N=Node, E=Edge>>;

The `N=Node`

syntax allows us to provide a concrete type, `Node`

, for the `N`

type parameter. Same with `E=Edge`

. If we didn’t provide this constraint, we
couldn’t be sure which `impl`

to match this trait object to.