an associated type
When you write a trait, sometimes a method's signature has to mention a type that is not fixed by the trait itself but is chosen by whoever implements it. Think of an iterator: every iterator yields elements, but a counter yields integers, a line reader yields strings, and a file walker yields paths. The trait wants to say 'calling next gives you back one of MY elements' without committing to what an element is. An associated type is a placeholder type written inside a trait, named there and filled in by each implementation, so the trait can talk about a related type that differs per implementor.
You declare one with type inside the trait, like trait Iterator { type Item; fn next(&mut self) -> Option<Self::Item>; }. Here Item is the associated type; the method refers to it as Self::Item. When you implement the trait, you pin Item down: impl Iterator for Counter { type Item = u32; ... }, fixing the element type to u32 for that one implementation. The natural question is why not just make it a generic parameter, trait Iterator<Item>. The difference is uniqueness: with an associated type, a given type implements Iterator exactly once and its Item is determined, so the compiler always knows what next returns without you spelling it out. With a generic parameter, a type could implement Iterator<u32> AND Iterator<String>, and every call site would have to say which — more flexible, but noisier. The rule of thumb is: use an associated type when there is one natural choice per implementor (an iterator has one element type), and a generic parameter when a type should implement the trait several ways.
Why this matters: associated types are why iterator code reads so cleanly — you write x.next() and the compiler knows the element type from the implementation, no annotations needed. They appear all over the standard library: Iterator::Item, Deref::Target, Add::Output, the error type in many traits. The honest distinction to keep is associated type (one per implementation, chosen by the implementor) versus generic trait parameter (many implementations possible, chosen by the caller); reaching for the wrong one makes a trait either too rigid or too noisy to use.
struct Counter { n: u32 } impl Iterator for Counter { type Item = u32; // this implementor's element type fn next(&mut self) -> Option<u32> { if self.n < 3 { self.n += 1; Some(self.n) } else { None } } } let total: u32 = Counter { n: 0 }.sum(); // compiler knows Item = u32 println!("{total}"); // 6 (1 + 2 + 3)
Item is named in the trait and fixed by each implementor, so the compiler always knows what next returns.
Reach for an associated type when each implementor has one natural choice (an iterator yields one element type); use a generic trait parameter when a type should implement the trait several different ways.