Traits

A trait is Rust's word for "a named collection of method signatures that any type can opt into." If you've used Java or C# interfaces, C++ abstract classes with pure virtual methods, Haskell type classes, Swift protocols, or Python's abc/Protocol, you already know the gist of it.

The Rust spelling is:

trait Greet {
    fn hello(&self) -> String;
}

struct English;
struct German;

impl Greet for English {
    fn hello(&self) -> String { "Hello!".to_string() }
}

impl Greet for German {
    fn hello(&self) -> String { "Hallo!".to_string() }
}

English and German have nothing in common structurally, but both "implement Greet." Anywhere code asks for a Greet, either will do.

You've actually been using traits since the enums chapter. Every time you wrote #[derive(Debug, PartialEq)] on an enum or struct, you were asking the compiler to write the impl Debug for ... and impl PartialEq for ... blocks for you. That's all derive is: a macro that emits the obvious implementation so you don't have to type it out. We'll revisit this in a moment.

From familiar traits to trait objects

The first exercise implements Display, a standard library trait, for a temperature type. Describable provides a bound for a generic function. Default methods share behavior between implementations without repetition. dyn Trait lets one collection hold values of different concrete types.

Standard library traits you've already met

None of those are magic. Each is a regular trait defined in std, with implementations for the built-in types where they make sense. When you derive one, the compiler writes the implementation. When the generated behavior isn't what you want, you write the implementation by hand.

Static vs. dynamic dispatch: a sneak preview

// Static dispatch: the compiler generates a specialized copy of
// `print_all` for each `T` you use it with. Zero runtime cost,
// but every `T` in one call must be the same concrete type.
fn print_all<T: Display>(items: &[T]) { /* ... */ }

// Dynamic dispatch: one function, one vtable lookup per call.
// The slice can mix different concrete types that all implement
// `Display`.
fn print_all_dyn(items: &[&dyn Display]) { /* ... */ }

You'll use both forms in the exercises below. For ownership, Box<dyn Trait> gives an unsized trait object a fixed-size handle.

Implementing `Display` for your own type

Display is the trait behind the {} placeholder in println!, format!, and friends. Implementing it for your struct means values of that struct can be formatted as user-facing text the same way a number or a String can.

The trait lives in std::fmt and looks like this:

pub trait Display {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result;
}

Don't be put off by the signature. In practice you write a one-liner that delegates to the write! macro, which has the same template syntax as println! but writes into the formatter:

use std::fmt;

struct Pixel(u8, u8, u8);

impl fmt::Display for Pixel {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "#{:02X}{:02X}{:02X}", self.0, self.1, self.2)
    }
}

After that, format!("{}", Pixel(255, 0, 0)) produces "#FF0000".

Why isn't there a #[derive(Display)]?

Because there's no obvious default. Debug has one (print the type name and fields), but Display is for human-readable output and only you know what that should look like for your type. So you write it by hand. The Java/C# parallel is overriding toString(); the Python one is __str__.

Useful from the standard library

• std::fmt::Display is the trait. use std::fmt; and then impl fmt::Display for T is the idiomatic spelling.
• write! is the formatter-targeted cousin of println!. It returns std::fmt::Result, which is exactly what your fmt method needs to return, so a single write!(...) call is usually the whole body.
• Format specifiers carry over: {:.1} rounds a float to one decimal place, so format!("{:.1}", 21.5_f64) is "21.5". You'll want that for the temperature output.

Defining your own trait

Now you're on the other side of the contract. Instead of impling a trait someone else wrote, you'll write the trait yourself, give two types their own implementation, and then write a generic function that accepts anything implementing it.

trait Describable {
    fn describe(&self) -> String;
}

That's the entire interface. Any type can opt in by writing impl Describable for MyType { fn describe(&self) -> String { ... } }.

Trait bounds on generics

Once a trait exists, you can use it as a bound on a generic parameter to say "I accept any T, as long as T implements this trait":

fn print_one<T: Describable>(item: &T) {
    println!("{}", item.describe());
}

This is Rust's answer to "polymorphism." The compiler stamps out one specialized copy of print_one per type you call it with (called monomorphization; the C++ template crowd will feel at home). There's no runtime dispatch and no boxing.

Real code often spells the same kind of bound in one of these forms:

// Multiple bounds with `+`:
fn show<T: Describable + std::fmt::Debug>(item: &T) { /* ... */ }

// Same thing, written with a `where` clause. Easier to read once you
// have several parameters or long bounds:
fn show<T>(item: &T)
where
    T: Describable + std::fmt::Debug,
{
    /* ... */
}

// `impl Trait` in argument position is shorthand for a single
// unnamed generic parameter:
fn show(item: &impl Describable) { /* ... */ }

For this exercise, use the simple <T: Describable> form. You only need to recognize the others as different spellings of the same machinery.

Useful from the standard library

• The Rust Book on traits walks through definitions, implementations, and bounds with more examples than fit here.
• Vec<String>::join("\n") (and any &[String].join(...)) is handy for the print_descriptions exercise: build a Vec<String> of per-item descriptions, then join them with newlines.
• The standard Iterator::map plus .collect::<Vec<_>>() is the idiomatic way to turn a &[T] into a Vec<String>. Iterator::map and collect appear throughout the iterator exercises.

Default methods

A trait method can ship with a default body. Implementors get that method for free, but any one of them can override it if the default doesn't fit.

trait Greet {
    fn name(&self) -> &str;

    // Default body. Implementors get this for free.
    fn hello(&self) -> String {
        format!("Hello, {}!", self.name())
    }
}

A type that says impl Greet for X { fn name(&self) -> &str { "world" } } automatically has .hello() available, returning "Hello, world!", without writing it out. Provide a fn hello in the impl block and yours wins instead.

This is how Iterator gets away with offering dozens of methods (map, filter, sum, count, ...) while only requiring you to implement one: fn next(&mut self) -> Option<Self::Item>. Every other method is a default body written in terms of next. Haskellers will recognise the pattern from type class default methods; Java added the same feature as "default methods on interfaces" in Java 8.

A logger with shared behavior

The Logger trait has one required method, log, which formats a single line. Its warn and error methods provide default bodies built on top of log.

trait Logger {
    fn log(&self, msg: &str) -> String;

    fn warn(&self, msg: &str) -> String {
        self.log(&format!("[WARN] {msg}"))
    }

    fn error(&self, msg: &str) -> String {
        self.log(&format!("[ERROR] {msg}"))
    }
}

The shape should look familiar from logging APIs in other languages. Because warn and error live on the trait, each new implementor gets both without writing them again.

You'll implement that contrast with two types:

1. PlainLogger returns the message untouched. It uses both defaults as written, so all you have to write is log.
2. TaggedLogger { tag: String } prepends a tag (e.g. "auth: ..."). It uses the default warn, but overrides error to swap the [ERROR] prefix for a louder [CRITICAL] prefix.

That asymmetry lets each implementor keep the defaults that fit and replace only the behavior that differs.

Useful from the standard library

• The format! macro is the workhorse here. Default warn builds "[WARN] {msg}" and hands it back to self.log, so whatever decoration log does (the tag, in TaggedLogger's case) wraps the warning prefix.
• Default methods are written inside the trait block, with a body instead of a trailing semicolon. A method ending in a semicolon remains required, while a method with a body can be inherited or overridden.

Trait objects: `dyn Trait`

The generic print_descriptions<T: Describable> from step 3 is fast and zero-cost, but it has one limit: every element of a single call must be the same concrete T. You can pass &[Book] or &[Movie], but not a slice that contains both.

That's because the compiler picks one T per call site and produces a specialized copy of the function for it. The slice type &[T] has to agree on a single element type, and two different structs are two different types as far as the type system is concerned.

Using dyn Trait

When you want a single collection that holds different concrete types as long as they all implement the same trait, you reach for a trait object, spelled dyn Trait:

fn run_all(items: &[&dyn Validator], input: &str) {
    for v in items {
        let _ = v.check(input);
    }
}

&dyn Validator is a fat pointer: two words that point to the value and to a vtable of function pointers, one for each trait method. At each call to .check(...), Rust looks up the function in that vtable. C++ folks will recognize the same machinery as virtual methods, but here you opt into it at the call site instead of on the class. run_all is also compiled exactly once rather than once per concrete type. That trades one vtable lookup per call for the ability to mix concrete types in the slice.

Static vs. dynamic dispatch, side by side

Neither is "better." Use generics by default for performance and flexibility, and reach for dyn Trait when you genuinely need heterogeneous storage or want a smaller binary.

A validation example

You'll use trait objects to build a small validation library. Each validator needs one method:

trait Validator {
    /// `Ok(())` on success, `Err(message)` on failure.
    fn check(&self, input: &str) -> Result<(), String>;
}

You'll give three structs one rule each:

• MinLength { n }: input must have at least n characters.
• MustContain { needle }: input must contain the given substring.
• MustNotContain { forbidden }: input must not contain the given substring.

MinLength, MustContain, and MustNotContain are different types, but one &[&dyn Validator] slice can hold all three. Each rule can carry its own configuration while the call site only needs a list of values that can validate.

If you take the optional password validator later, you'll use the same idea for a configurable set of checks.

A word about Box<dyn Trait>

You'll also see Box<dyn Trait> in Rust code:

let rules: Vec<Box<dyn Validator>> = vec![
    Box::new(MinLength { n: 8 }),
    Box::new(MustContain { needle: "@".to_string() }),
];

The reason: dyn Trait has no statically known size (the three implementors above can carry different fields, so they don't all take up the same number of bytes), so the compiler won't let you put bare dyn Validator values directly in a Vec. A Box is a heap allocation with a fixed-size pointer that lives on the stack, which sidesteps the size problem. Box<dyn Trait> is the owning form of this fixed-size handle. &dyn Validator borrows through a fixed-size handle instead of taking ownership.

Useful from the standard library

• The Rust Book on trait objects.
• str::contains (with a &str argument) is all you need for the MustContain / MustNotContain checks.
• Inside collect_errors, a plain for loop pushing into a Vec<String> is the most direct form. An .iter().filter_map(...) chain expresses the same loop with iterator adapters.

Wrapping up traits

You implemented the standard library's Display trait and defined a Describable trait of your own. You used Describable as a generic bound, then shared behavior through default methods. Finally, you switched from a generic to a trait object so one slice could hold several kinds of validation rule.

What we learned

• A trait is a named collection of method signatures. Any type can opt in with impl TraitName for TypeName { ... }. Same idea as Java/C# interfaces, Haskell type classes, Swift protocols, or C++ abstract classes with pure virtual methods.
• #[derive(...)] is sugar: the compiler writes the obvious impl Trait for Type block for you. Debug, PartialEq, Eq, Clone, Copy, Default, Hash, and Ord are the everyday derivable ones. Display is not derivable because there's no one-size-fits-all human-readable format.
• impl Display is the toString / __str__ of Rust. Implement fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result with a single write!(...) call.
• Trait bounds on a generic say "I accept any T that implements this trait." fn f<T: Trait>(x: &T) is the basic form, T: A + B combines bounds, and where clauses let you push long bounds out of the signature.
• Default methods in the trait body give every implementor a baseline behavior. Override per type when you need to.
• Generics dispatch statically, so the compiler creates one specialized copy of the function per concrete T. Use them when each call only needs one concrete type.
• Trait objects (dyn Trait) dispatch dynamically through a vtable. Use them when one slice or Vec needs to hold several concrete types at once.
• Box<dyn Trait> solves the "trait objects have no known size" problem so they can live in owning containers like Vec. Related ownership patterns with Box, Rc, and RefCell appear in the optional smart pointers material.
• Many standard library traits you already use (Iterator, From, Into, PartialEq, ...) follow the same rules. You can define traits of your own or implement standard traits for your own types.