Associated types vs generic type parameters in traits

WHAT THIS TESTS Whether you understand the distinction between input and output type positions in traits, and how that choice affects ergonomics and the number of valid implementations a type can have.

A GOOD ANSWER COVERS An associated type is an output type chosen by the implementer; each type implements the trait at most once, so the associated type is uniquely determined. A generic trait parameter is an input type chosen by the caller, allowing a single type to implement the trait many times with different parameters. The canonical example is Iterator, which declares type Item. Because Item is associated, calling next on any iterator gives the compiler exactly one Option<Item> to infer, so let x = it.next() needs no turbofish. If Iterator had been Iterator<Item>, every iterator could in principle yield multiple Item types and inference would frequently require annotation.

COMMON WRONG ANSWERS Claiming the two are interchangeable, or that generics are strictly more flexible and therefore preferable. Also wrong: saying you can implement Iterator several times for one struct with different Item types. You cannot, precisely because Item is associated.

LIKELY FOLLOW-UPS When would you prefer a generic parameter? When one type genuinely needs multiple implementations, such as From<T> or Add<Rhs>, where i32 implements Add<i32> and Add<&i32>. They may ask about combining both, as in Iterator using an associated Item alongside generic adapter methods, or about associated constants and generic associated types.

ONE CONCRETE EXAMPLE Consider a Graph trait with associated types Node and Edge. A caller writing fn count<G: Graph>(g: &G) -> usize never repeats the node or edge types, and methods returning G::Node read cleanly. Had Graph been generic over Node and Edge, every signature would carry three parameters and inference would degrade, illustrating why associated types win when the relationship is one-to-one.