Rust Auto-Dereferencing Rules in Method Calls Explained

By the end of this page, you will understand how Rust resolves value.method() calls by building candidate receiver types, applying repeated dereferencing, and then trying automatic borrowing with & and &mut where appropriate. You will also see how Deref affects method lookup, why methods with self, &self, and &mut self behave differently, and how these rules make smart pointers and references ergonomic in real Rust code.

Rust method calls use more than simple dot syntax. When you write:

value.method()

Rust does method receiver lookup. It does not only check the exact type of value. Instead, it tries a series of possible receiver forms until it finds a method that matches.

The core idea

For a method call, Rust conceptually does two things:

1. Builds candidate receiver types from the expression on the left side of the dot.
2. Searches for a matching method on those candidates.

The candidate list is built by repeatedly applying:

• built-in dereferencing of references like &T -> T
• user-defined dereferencing through Deref (and DerefMut in mutable cases)
• then, for each candidate type T, Rust also considers borrowed forms like &T and &mut T when valid

That is why a method defined on T may be callable on &T, Box<T>, Rc<T>, or your own smart-pointer-like type if Deref is implemented.

Think of Rust method lookup like trying keys on a ring.

You start with the exact value on the left of the dot.

If that key does not open the door, Rust tries nearby variations:

• the value itself
• one dereference away
• two dereferences away
• borrowed versions like &value
• mutable borrowed versions when allowed

It keeps trying sensible receiver shapes until it finds a method that fits.

Analogy

Imagine you have a package inside several layers:

• T
• &T
• &&T
• Box<T>
• custom wrapper types using Deref

Rust method lookup is like peeling layers or temporarily holding the package differently until it can hand it to the method in the form the method expects.

• If the method wants to look at the package, Rust can often borrow it as &self.
• If the method wants to change the package, Rust may borrow it as &mut self.
• If the method wants to take the package, Rust must be able to move or copy the value.

That last point explains many edge cases: borrowing is easy, but moving through a reference is restricted.

Basic receiver forms

struct User {
    name: String,
}

impl User {
    fn by_value(self) {
        println!("owned: {}", self.name);
    }

    fn by_ref(&self) {
        println!("borrowed: {}", self.name);
    }

    fn by_mut_ref(&mut self) {
        self.name.push('!');
    }
}

Auto-borrow with &self

fn main() {
    let user = User {
        name: "Ana".to_string(),
    };

    user.by_ref();
}

Even though by_ref expects &self, Rust automatically borrows as .

Consider this example:

use std::ops::Deref;

struct X {
    val: i32,
}

impl Deref for X {
    type Target = i32;

    fn deref(&self) -> &i32 {
        &self.val
    }
}

trait RefM {
    fn refm(&self);
}

impl RefM for i32 {
    fn refm(&self) {
        println!("i32::refm()");
    }
}

impl RefM for X {
    fn refm(&self) {
        println!("X::refm()");
    }
}

fn main() {
    let value = &X { val:  };
    value.();
}

Calling methods on smart pointers

Rust code frequently uses pointer-like types:

• Box<T>
• Rc<T>
• Arc<T>
• String
• custom wrappers implementing Deref

Auto-deref lets you call inner methods naturally:

let name = Box::new(String::from("rust"));
println!("{}", name.len());

Working with shared application state

In web servers or async applications, values are often wrapped in Arc<T>.

use std::sync::Arc;

struct Config {
    app_name: String,
}

impl Config {
    fn app_name(&self) -> & {
        &.app_name
    }
}

 () {
      = Arc::(Config {
        app_name: .(),
    });

    (, config.());
}

Common pattern: mostly &self methods

In real Rust projects, many methods are defined with &self because:

• they do not consume the value
• they are easier to call
• they work well with references and smart pointers

struct Parser {
    source: String,
}

impl Parser {
    fn len(&self) -> usize {
        self.source.len()
    }
}

Smart-pointer ergonomics

Libraries rely on Deref so wrapped values remain easy to use.

use std::rc::Rc;

struct Service {
    name: String,
}

impl Service {
    fn name(&self) -> &str {
        &self.name
    }
}

fn print_service(service: Rc<Service>) {
    (, service.());
}

Mistake 1: Assuming method-call auto-deref applies everywhere

Method syntax is special.

struct User;

impl User {
    fn greet(&self) {}
}

fn main() {
    let user = &User;
    user.greet(); // works

    // User::greet(user); // this is different style and may not feel as flexible
}

How to avoid it

Remember that value.method() has receiver lookup rules that are more ergonomic than ordinary function calls.

Mistake 2: Thinking Deref means “implicit conversion everywhere”

Deref mainly helps with:

• method calls
• deref coercions in some reference contexts

It is not a universal automatic conversion mechanism.

use std::ops::Deref;

struct Wrapper(String);

impl Deref for  {
      = ;

     (&)  & {
        &.
    }
}

self vs &self vs &mut self

Method-call syntax vs function-call syntax

Receiver lookup quick reference

When resolving:

value.method()

Rust roughly:

1. Starts from the type of value
2. Repeatedly dereferences it
   • built-in deref for references
   • Deref / DerefMut where applicable
3. For each candidate type, also considers borrowed forms
   • &T
   • &mut T when allowed
4. Chooses a matching visible method

Common receiver forms

fn a(self)
fn b(&self)
fn c(&mut self)

What usually works

let s = String::from("abc");
s.();      

  = &s;
r.();      

  = ::(::());
b.();      

Why can I call a &self method on a value without writing &?

Because Rust automatically borrows the receiver in method-call syntax when the method expects &self.

Why does calling a self method on &T sometimes fail?

Because self means ownership. Rust cannot move a non-Copy value out of a shared reference.

Does Deref apply only to method calls?

No. It also affects deref coercions in some reference contexts, but method calls are where it is most visible.

Why does a wrapper type gain methods from its inner type?

If the wrapper implements Deref<Target = Inner>, Rust can continue method lookup on Inner.

Is auto-deref the same as implicit type conversion?

No. It is a specific receiver-lookup and coercion mechanism, not general implicit conversion.

When should I implement Deref?

Usually for smart pointers or very transparent wrappers. Avoid it for arbitrary business-domain conversions.

Why is method-call syntax more flexible than Type::method(value)?

• Ownership — auto-deref still respects ownership and move rules.
• Borrowing — method lookup often inserts immutable or mutable borrows.
• References — built-in dereferencing starts with &T and &mut T.
• Deref trait — custom dereferencing is central to smart-pointer-like behavior.
• Deref coercion — related mechanism that converts references in certain contexts.
• Method syntax — Rust treats value.method() specially during lookup.
• Traits — trait methods participate in method resolution.
• Smart pointers — types like Box, Rc, and Arc rely heavily on these rules.
• Copy trait — explains why some by-value method calls through references work.
• Fully qualified syntax — useful when method resolution is ambiguous or needs explicit control.