Deref Coercion

Ask a Box<String> for its length and it answers:

let b: Box<String> = Box::new(String::from("hello"));
assert_eq!(b.len(), 5);            // Box has no len(); String does
assert_eq!(b.as_bytes(), b"hello"); // and str has as_bytes; the chain keeps going

Nothing about Box declares len. What exists is one method — the Deref trait's single required function:

pub trait Deref {
    type Target;
    fn deref(&self) -> &Self::Target;
}

impl Deref for Box<T> { type Target = T; fn deref(&self) -> &T { /* std-internal */ } }   // schematic

Method resolution walks that implementation as a chain. When you write b.len(), the compiler tries the receiver in order: Box<String> (no), &Box<String> (no), &mut Box<String> (no), then applies deref once to reach String and tries again, then once more to reach str — where len() exists. Call it the autoderef ladder: each rung is one Deref::deref call, and the first rung with a matching method wins. Field access and indexing climb the same ladder, which is why Box::new((1, 2)).0 and b[0] on a boxed Vec compile without a single explicit *.

The ladder is what makes a smart pointer smart instead of merely annoying:

use std::ops::{Deref, DerefMut};

struct UserCache { hits: u32, store: std::collections::HashMap<String, String> }

impl Deref for UserCache {
    type Target = std::collections::HashMap<String, String>;
    fn deref(&self) -> &Self::Target { &self.store }
}

let cache = UserCache { hits: 0, store: Default::default() };
assert!(cache.get("key").is_none());   // HashMap methods reachable through the wrapper

One Deref impl gave the wrapper every HashMap method, and DerefMut (chapter 3) will give it every &mut method too. That is the legitimate use of the trait: a newtype that genuinely is its inner value for reading, or a pointer to one. The standard library's own docs warn against the illegitimate use — implementing Deref to simulate inheritance or to convert between unrelated types. For conversion, the explicit tools are From/Into, AsRef, and Borrow; Deref exists so that pointers behave transparently, not so APIs can hide their signatures.

Two clarifications keep the model precise. First, autoref happens at every rung: before dereferencing, the compiler tries the value itself, then &T, then &mut T — which is how boxed_vec.push(1) finds Vec::push(&mut self) through &mut Box<Vec<_>>. Second, the whole ladder is static: nothing runs, nothing allocates, and you can always spell a rung yourself when inference needs the help:

fn width(s: &str) -> usize { s.len() }

let b: Box<String> = Box::new(String::from("hello"));
width(&b);          // ladder + coercion: &Box<String> -> &String -> &str
width(&*b);         // one explicit deref: &String (then coerces)
width(&**b);        // two: &str directly — ugly, but it is the mechanism made visible

&*b is the manual rung, and it is exactly what you reach for when a generic signature defeats coercion (next chapter). Finally, know the ladder's cast of characters in std — the Target of each tells you what becomes reachable: Box<T>/Rc<T>/Arc<T> → T, Vec<T> → [T], String → str, PathBuf → Path, Cow<str> → str, Cell<T>/RefCell<T> → T. Half of Rust's "why does this method exist here?" questions are answered by one row of that list.

Interview framing: "Why does b.len() work?" is the standard opener for this topic. A complete answer names Deref, walks the ladder (Box → String → str), and adds that field access and indexing deref as well — then says where you should not implement it. The ladder is also the mechanism behind the conversions in the next chapter; the pointer itself comes from Box for Heap Allocation.

fn log(msg: &str) { println!("{msg}"); }

let owned = String::from("boot");
log(&owned);          // &String handed over, &str expected — compiles

No &owned[..], no .as_str(). The compiler converts &String into &str at the call, because String: Deref<Target = str> and the parameter's type is known. That automatic conversion is deref coercion, and it only fires where the compiler already knows what type it wants:

Coercions also chain, because the compiler keeps dereferencing until the expected type appears — this is the part people underestimate:

fn size(s: &str) -> usize { s.len() }

let s = String::from("hello");
size(&s);                       // &String  -> &str          (one step)
size(&Box::new(s));             // &Box<String> -> &String -> &str   (two steps)
size(&Rc::new(String::from("x"))); // &Rc<String> -> &String -> &str  (via Deref for Rc)

Each intermediate type must implement Deref with the right Target, so the same rule explains &Vec<T> → &[T], &PathBuf → &Path, and &Box<dyn Error> → whatever it points at.

Where coercion does not happen is equally worth memorizing: wherever there is no expected type, there is no coercion. Generic parameters are the classic case:

fn count<T: AsRef<[u8]>>(data: T) -> usize { data.as_ref().len() }

let owned = vec![1_u8, 2, 3];
count(&owned);          // T is inferred as &Vec<u8>, NOT coerced to &[u8]

With a concrete fn f(x: &[u8]) the argument type is fixed, so coercion fires; with T the compiler infers whatever unifies — &Vec<u8> unifies fine, so no conversion is attempted, and code that later treats T as a slice can fail in a surprising place. The fix is always explicit: count(vec.as_slice()), count(&*owned), or a bound that describes what you mean (AsRef<[u8]>, as above).

Reading the failure is half the skill. When the expected type is known but no deref path reaches it, the compiler names the mismatch right at the site:

error[E0308]: mismatched types
  |
4 |     width(&data);
  |           ^^^^^^ expected `&str`, found `&Vec<u8>`

&Vec<u8> coerces to &[u8], never to &str — the ladder's Target chain decides which conversions exist, and no amount of expectation can invent a missing Deref impl. The other two coercion families share these sites but are not deref: unsized coercion (&[T; 3] → &[T], Box<Concrete> → Box<dyn Trait>) replaces the type's metadata instead of chasing pointers, and pointer-mutability coercion (&mut T → &T, allowed in that direction only) weakens exclusivity. All three fire only where an expected type exists; none survive into generic inference.

The other non-sites: operator operands and match scrutinees get no coercion (operators resolve through Trait impls instead — &String == &str works because of a PartialEq impl, not because of Deref), and method receivers are not coercion sites either — they use the autoderef ladder from chapter 1, which is a separate mechanism that happens to share its implementation.

Interview framing: expect to be asked both halves: "why does this compile?" (&String → &str at a known call site, chained through Deref) and "why doesn't this compile?" (a generic parameter, an operator, an unannotated let). Naming the expected-type requirement is the discriminator between someone who has read the rules and someone who has felt them.

Reads are only half the story. Mutation through a smart pointer goes through a second trait with the same shape:

pub trait DerefMut: Deref {
    fn deref_mut(&mut self) -> &mut Self::Target;
}

DerefMut powers everything that needs &mut at the end of the ladder:

let mut b: Box<Vec<u32>> = Box::new(vec![1, 2]);
b.push(3);                       // DerefMut -> &mut Vec<u32> -> push

let mut s: Box<String> = Box::new(String::from("hi"));
let view: &mut str = &mut *s;    // explicit step...
let view2: &mut str = &mut s;    // ...or coercion at the site, same conversion

The second form is the mutable twin of &String → &str: at a site expecting &mut str, the compiler walks &mut Box<String> → &mut String → &mut str, requiring DerefMut at every rung — a read-only Deref impl is not enough for mutation, and a type that implements Deref without DerefMut therefore refuses mutation no matter how the pointer is used. (Rc does this deliberately: DerefMut must hand out &mut unconditionally, and with several handles "unconditionally" would mean several writers to one value.) The wrapper from chapter 1 completes itself the same way:

struct Counter { value: u32 }
impl std::ops::Deref for Counter {
    type Target = u32;
    fn deref(&self) -> &u32 { &self.value }
}
impl std::ops::DerefMut for Counter {
    fn deref_mut(&mut self) -> &mut u32 { &mut self.value }
}

let mut c = Counter { value: 0 };
*c += 1;               // place expression derefs mutably -> &mut u32 -> AddAssign
println!("{}", c);     // read path shows every u32 method too

Note the syntax: *c += 1 names the deref explicitly (operators themselves do not autoderef — c += 1 would demand AddAssign on Counter), while method calls and coercions insert the deref for you. The ladder hands out access; it does not relax aliasing. Two mutable steps through the same pointer still collide:

let a = &mut *b;
let c = &mut *b;    // error[E0499]: cannot borrow `*b` as mutable more than once

DerefMut grants the capability to take &mut T through the pointer — the borrow checker still decides how many such borrows may coexist, which is why the smart-pointer topics and the borrow-checker topics are the same story told from two sides.

Mutation also explains why indexing assigns: v[0] = 9 desugars through IndexMut, and the base expression autoderefs exactly like method receivers — boxed[0] = 9 on a Box<Vec<i32>> works for the same ladder reason boxed.push does. Similarly mem::swap(&mut *a, &mut *b) on boxed values is only spelling out the deref that coercion would insert.

Now the design rule, which is where interviews go deep: Deref makes an implicit promise. Implement it on a wrapper and every method of the target becomes visible on your type — callers can no longer see where your API ends and HashMap's begins. That is right for Box/Rc/Vec (the wrapper is a pointer; its Target is the whole point) and for newtypes whose identity is the inner value. It is wrong for "convenience conversions" between unrelated types — those belong to From, AsRef, or an explicit .inner() method, because implicit conversions hide cost and surprise callers. When you are asked "should my type implement Deref?", the answer is: only if it is a pointer to Target.

Interview framing: the full sequence an interviewer wants is: autoderef ladder (methods, fields, indexing) → coercion sites and the expected-type requirement → DerefMut for writes → the design warning about abusing Deref. With pointers now fully explained, the roadmap turns to what happens when you need several owners: Rc for Shared Ownership.