In [this question](https://stackoverflow.com/q/32053402/155423), an issue arose that could be solved by changing an attempt at using a generic type parameter into an associated type. That prompted the question "Why is an associated type more appropriate here?", which made me want to know more.

The [RFC that introduced associated types](https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.md) says:

> 
> This RFC clarifies trait matching by:
> 
> 
> * Treating all trait type parameters as *input types*, and
> * Providing associated types, which are *output types*.
> 
> 
> 

The RFC uses a graph structure as a motivating example, and this is also used in [the documentation](https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#specifying-placeholder-types-in-trait-definitions-with-associated-types), but I'll admit to not fully appreciating the benefits of the associated type version over the type-parameterized version. The primary thing is that the `distance` method doesn't need to care about the `Edge` type. This is nice but seems a bit shallow of a reason for having associated types at all.

I've found associated types to be pretty intuitive to use in practice, but I find myself struggling when deciding where and when I should use them in my own API.

When writing code, when should I choose an associated type over a generic type parameter, and when should I do the opposite?