Traits are constraints, not types

Part 3 is the trait solver: the second machine from 0.2, the one that runs before your program does.

This lesson fixes the framing everything else depends on.

This is not pedantry. Once you read T: Display as a constraint on a type variable rather than as T is a subtype of Display, generic signatures stop looking like object-oriented code with strange syntax, and the whole of 3.6 becomes readable.

Nominal and explicit

That last row is the interesting combination. In Java, the set of interfaces a class implements is fixed by whoever wrote the class. In Rust, the impl block is a separate item, so you can implement your own trait for String, u32, or someone else’s struct:

trait Shout { fn shout(&self) -> String; }

impl Shout for str {
    fn shout(&self) -> String { self.to_uppercase() + "!" }
}

// now:  "hello".shout()

This is the extension trait pattern, and it is everywhere in the ecosystem — itertools::Itertools adds dozens of methods to every iterator, futures::StreamExt does the same for streams.

Coherence and the orphan rule

Because impls are separate from type definitions, a question arises that Java never has to answer: what if two crates both implement the same trait for the same type?

Rust’s answer is coherence: for any trait/type pair there is exactly one implementation in the whole program. Not one per crate — one, globally.

The orphan rule enforces it locally: to write impl Trait for Type, at least one of Trait or Type must be defined in your crate.

use std::fmt::Display;

struct MyType;
trait MyTrait { fn go(&self); }

// A
impl Display for MyType { /* ... */ }

// B
impl MyTrait for String { fn go(&self) {} }

// C
impl Display for Vec<u8> { /* ... */ }

// D
impl MyTrait for Vec<MyType> { fn go(&self) {} }

struct Bytes(Vec<u8>);
impl Display for Bytes { /* ... */ }   // Bytes is local — allowed

Blanket impls

Because a trait is a predicate, you can implement it for every type satisfying another predicate:

impl<T: Display> ToString for T {
    fn to_string(&self) -> String { /* ... */ }
}

One impl, covering every Display type that exists or will ever be written. That is a blanket impl, and it is a genuinely different capability from anything in Java or Go.

It is also why you should almost never implement ToString yourself — implement Display and get ToString free. A reviewer noticing that is a small but real signal of familiarity.

The cost is that blanket impls interact with coherence. Adding one to a published crate can break downstream code that already had its own impl, which is why they are semver-sensitive and why library authors think hard before shipping one.

Associated types versus generic parameters

Both appear inside traits and they look similar. The difference is how many times a type may implement the trait.

trait Iterator {
    type Item;                            // associated type
    fn next(&mut self) -> Option<Self::Item>;
}

trait From<T> {                           // generic parameter
    fn from(value: T) -> Self;
}

• Iterator::Item is associated, so a type implements Iterator at most once. That is right: a Vec<u8> iterator yields u8, and there is no second sensible answer.
• From<T> is parameterised, so a type can implement it many times. String implements From<&str>, From<char>, From<Box<str>> and more.

The rule of thumb for reading: associated type means “one answer per type”; generic parameter means “many answers allowed”. When you see a trait with an associated type, you know the author considered it unique.

You will also see associated types written as constraints:

fn sum_all<I>(iter: I) -> u32
where
    I: Iterator<Item = u32>,      // constrain the associated type
{ iter.sum() }

Iterator<Item = u32> is not a generic argument — it is a constraint on the associated type, using = rather than a bare parameter. Recognising that syntax is worth a lot when reading real signatures.

Supertraits and default methods

trait Animal {
    fn name(&self) -> String;

    fn greet(&self) -> String {           // default method
        format!("Hello, {}", self.name())
    }
}

trait Pet: Animal {                       // supertrait
    fn owner(&self) -> String;
}

trait Pet: Animal reads “anything implementing Pet must also implement Animal”. It looks like inheritance and is not — there is no shared data and no overriding; it is a requirement, one predicate implying another.

Default methods are how traits like Iterator provide ninety methods while requiring implementors to write only next. When you read a big trait, the question is always: which methods are required and which have defaults? The docs mark this clearly, and it tells you how much work implementing it is.

What you should now be able to say

• A trait is a predicate over types, not a type. dyn Trait is the type.
• Implementation is nominal and explicit, but the impl block is separate from the type — which enables extension traits.
• Coherence: one impl per trait/type pair, globally. The orphan rule enforces it; newtype is the workaround.
• Blanket impls implement a trait for every type satisfying another bound.
• Associated type = one answer per type. Generic parameter = many.
• trait A: B is a requirement, not inheritance.

Next: 3.3 — Dispatch and monomorphisation, where constraints turn into machine code and the costs become visible.