Parts 1 through 5 built up the ownership, borrowing, and lifetime foundation. By now you know how to annotate structs and read function signatures. Part 6 takes that further – into trait definitions, trait objects, and higher-ranked trait bounds. These are the tools that power flexible library APIs and generic abstractions in real Rust codebases.
Lifetime Bounds on Trait Implementations
Sometimes you want a trait to be implemented only for types that meet a lifetime requirement. This is done with a lifetime bound using the : syntax, just like trait bounds:
use std::fmt::Debug;
// T must implement Debug AND must be valid for the 'static lifetime
fn log_value(value: T) {
println!("{:?}", value);
}
fn main() {
log_value(42); // i32 is 'static - fine
log_value(String::from("hello")); // String is 'static - fine
let s = String::from("temp");
// log_value(&s); // ERROR: &s is not 'static
} The bound T: 'static does not mean T must be a global constant. It means T contains no borrowed references with limited lifetimes – it either owns all its data or contains only 'static references. Owned types like String, Vec, and i32 satisfy 'static. A &str reference to a local variable does not.
Lifetime Bounds on Trait Definitions
You can require that any type implementing a trait satisfies a lifetime constraint:
// Any type implementing Serialize must be 'static
trait Serialize: 'static {
fn serialize(&self) -> Vec;
}
// This works - String owns its data
impl Serialize for String {
fn serialize(&self) -> Vec {
self.as_bytes().to_vec()
}
}
// This does NOT work - &str borrows, not 'static
// impl<'a> Serialize for &'a str { ... } // would fail the 'static bound This pattern appears in async runtimes and thread pools where tasks need to be stored and potentially moved across thread boundaries without borrowed data becoming invalid.
Trait Objects and Lifetimes
A trait object (dyn Trait) erases the concrete type behind a pointer. When a trait object holds or produces references, you need to specify its lifetime. The default lifetime for a trait object depends on context:
trait Greet {
fn greet(&self) -> &str;
}
// These are equivalent - default lifetime for Box is 'static
fn make_greeter() -> Box { todo!() }
fn make_greeter_explicit() -> Box { todo!() }
// When used behind a reference, default lifetime comes from the reference
fn use_greeter(g: &dyn Greet) { println!("{}", g.greet()); }
// Equivalent to:
fn use_greeter_explicit<'a>(g: &'a (dyn Greet + 'a)) { println!("{}", g.greet()); } The default lifetime rules for trait objects:
- Inside
Box<dyn Trait>: defaults to'static - Inside
&'a dyn Trait: defaults to'a - Inside
&'a mut dyn Trait: defaults to'a
When you need to store a trait object that borrows data, you must be explicit:
trait Processor {
fn process(&self, input: &str) -> String;
}
struct Pipeline<'a> {
// trait object that may borrow data with lifetime 'a
steps: Vec>,
}
impl<'a> Pipeline<'a> {
fn new() -> Self {
Pipeline { steps: Vec::new() }
}
fn add_step(&mut self, step: impl Processor + 'a) {
self.steps.push(Box::new(step));
}
fn run(&self, input: &str) -> String {
self.steps.iter().fold(input.to_string(), |acc, step| {
step.process(&acc)
})
}
}
struct PrefixAdder<'a> {
prefix: &'a str, // borrows from somewhere
}
impl<'a> Processor for PrefixAdder<'a> {
fn process(&self, input: &str) -> String {
format!("{}{}", self.prefix, input)
}
}
fn main() {
let prefix = String::from("Hello, ");
let mut pipeline = Pipeline::new();
pipeline.add_step(PrefixAdder { prefix: &prefix });
println!("{}", pipeline.run("world")); // "Hello, world"
} flowchart TD
A["Box<dyn Trait>"] -->|default| B["'static bound\nType owns all data"]
C["&'a dyn Trait"] -->|default| D["'a bound\nType valid for 'a"]
E["Box<dyn Trait + 'a>"] -->|explicit| F["Type may borrow\nwith lifetime 'a"]
G["Vec<Box<dyn Trait + 'a>>"] -->|explicit collection| H["Collection of trait objects\nthat may hold 'a borrows"]
style B fill:#2c3e50,color:#ecf0f1
style D fill:#2c3e50,color:#ecf0f1
style F fill:#27ae60,color:#fff
style H fill:#27ae60,color:#fff
Higher-Ranked Trait Bounds
Higher-ranked trait bounds (HRTBs) are one of the more advanced lifetime features. They express that a trait must be implemented for all possible lifetimes, not just a specific one. The syntax is for<'a>:
// This function takes a closure that must work for ANY lifetime 'a
// The closure can accept a &str of any lifetime
fn apply_to_str(f: F, s: &str) -> usize
where
F: for<'a> Fn(&'a str) -> usize,
{
f(s)
}
fn main() {
let result = apply_to_str(|s| s.len(), "hello world");
println!("{}", result); // 11
} Without for<'a>, you would need to name a specific lifetime upfront, which would tie the closure to that one lifetime. With for<'a>, you are saying the closure must be able to accept a reference of any lifetime – it is quantified over all lifetimes.
In practice, for<'a> appears most often with Fn traits:
// Common HRTB patterns you will encounter
fn takes_any_ref_fn(f: F)
where
F: for<'a> Fn(&'a str) -> &'a str,
{
let s = String::from("test");
let result = f(&s);
println!("{}", result);
}
// The Fn, FnMut, FnOnce traits often implicitly use HRTBs
// These two bounds are equivalent:
fn equivalent1 usize>(f: F) {}
fn equivalent2 Fn(&'a str) -> usize>(f: F) {} The compiler often inserts HRTBs automatically when you write Fn(&str). The explicit for<'a> form becomes necessary when you need to express the relationship between input and output lifetimes in a closure bound.
Lifetime Parameters on Trait Methods
Traits can define methods that introduce their own lifetime parameters, independent of any lifetime on the trait itself:
trait Splitter {
// Each call to split can have its own lifetime
fn split<'a>(&self, input: &'a str) -> Vec<&'a str>;
}
struct WhitespaceSplitter;
impl Splitter for WhitespaceSplitter {
fn split<'a>(&self, input: &'a str) -> Vec<&'a str> {
input.split_whitespace().collect()
}
}
fn main() {
let splitter = WhitespaceSplitter;
let text = String::from("the quick brown fox");
let words = splitter.split(&text);
println!("{:?}", words); // ["the", "quick", "brown", "fox"]
}The Iterator Trait and Lifetimes
The standard library Iterator trait uses an associated type Item that can involve lifetimes. This is where the LendingIterator problem comes from – a limitation of the current trait system that affects certain iterator designs:
// Standard Iterator: Item is a fixed type, not tied to the borrow of self
trait Iterator {
type Item;
fn next(&mut self) -> Option;
}
// This works fine for owned items
struct Counter {
count: u32,
}
impl Iterator for Counter {
type Item = u32;
fn next(&mut self) -> Option {
self.count += 1;
if self.count <= 5 { Some(self.count) } else { None }
}
}
// The problem: you cannot express "Item borrows from self" in stable Rust
// This pattern requires GATs (Generic Associated Types) introduced in Rust 1.65
trait LendingIterator {
type Item<'a> where Self: 'a; // Generic Associated Type
fn next<'a>(&'a mut self) -> Option>;
} Generic Associated Types (GATs) solve a long-standing limitation where iterator items could not borrow from the iterator itself. This matters for streaming parsers, zero-copy deserializers, and any pattern where you want to yield references into internal storage. GATs are stable as of Rust 1.65 and increasingly appear in production library APIs.
Lifetime Bounds in Where Clauses
For complex generic functions, where clauses keep lifetime and trait bounds readable:
use std::fmt::{Debug, Display};
fn process_and_log<'a, T, E>(
value: &'a T,
on_error: &'a E,
) -> &'a T
where
T: Display + Debug,
E: Display,
T: 'a,
E: 'a,
{
println!("Processing: {}", value);
value
}
// Equivalent but harder to read inline:
fn process_and_log_inline<'a, T: Display + Debug + 'a, E: Display + 'a>(
value: &'a T,
on_error: &'a E,
) -> &'a T {
println!("Processing: {}", value);
value
}Implementing Traits That Return References
A common pattern is implementing Deref or custom accessor traits that return references. These require careful lifetime handling:
use std::ops::Deref;
struct MyBox(T);
impl Deref for MyBox {
type Target = T;
// &self has lifetime 'a, return &T also lives for 'a (Rule 3)
fn deref(&self) -> &Self::Target {
&self.0
}
}
// Custom indexed access with lifetime
trait Get<'a> {
type Output: 'a;
fn get(&'a self, index: usize) -> Option;
}
struct StringPool {
strings: Vec,
}
impl<'a> Get<'a> for StringPool {
type Output = &'a str;
fn get(&'a self, index: usize) -> Option<&'a str> {
self.strings.get(index).map(String::as_str)
}
} Common Mistakes With Trait Lifetimes
Mistake 1: Forgetting the Lifetime on dyn Trait in a Struct
trait Handler {
fn handle(&self, input: &str) -> String;
}
// DOES NOT COMPILE without 'a on the trait object
struct Router {
handlers: Vec>, // defaults to 'static
}
// If your Handler implementations borrow data, you need:
struct Router<'a> {
handlers: Vec>,
} Mistake 2: Using ‘static When You Mean ‘a
// Too restrictive - forces all implementations to be 'static
fn register(handler: T) { todo!() }
// Better - allows borrowed implementations too
fn register<'a, T: SomeTrait + 'a>(handler: T) { todo!() } Mistake 3: Not Recognizing Implicit HRTBs
// When the compiler rejects this with a confusing lifetime error:
fn broken &str>(f: F, s: &str) -> &str {
f(s)
}
// The issue is the return type - what lifetime does it have?
// You need to express that input and output lifetimes are linked:
fn fixed(f: F, s: &str) -> &str
where
F: for<'a> Fn(&'a str) -> &'a str,
{
f(s)
} What Comes Next
With trait lifetimes covered, you now have the full picture of how lifetimes propagate through functions, structs, enums, and traits. Part 7 moves to a different dimension of ownership: smart pointers and interior mutability. Box, Rc, Arc, RefCell, Cell, and Mutex – when each one is the right tool and what trade-offs each involves.
References
- The Rust Programming Language – “Traits: Defining Shared Behavior” (https://doc.rust-lang.org/book/ch10-02-traits.html)
- The Rustonomicon – “Higher-Ranked Trait Bounds” (https://doc.rust-lang.org/nomicon/hrtb.html)
- The Rust Reference – “Trait and Lifetime Bounds” (https://doc.rust-lang.org/reference/trait-bounds.html)
- Rust Blog – “Generic Associated Types Stabilization” (https://blog.rust-lang.org/2022/10/28/gats-stabilization.html)
- Rust Standard Library – “Deref Trait” (https://doc.rust-lang.org/std/ops/trait.Deref.html)
