What are Rust’s exact auto-dereferencing rules?

by

Your pseudo-code is pretty much correct. For this example, suppose we had a method call foo.bar() where foo: T. I’m going to use the fully qualified syntax (FQS) to be unambiguous about what type the method is being called with, e.g. A::bar(foo) or A::bar(&***foo). I’m just going to write a pile of random capital letters, each one is just some arbitrary type/trait, except T is always the type of the original variable foo that the method is called on.

The core of the algorithm is:

  • For each “dereference step” U (that is, set U = T and then U = *T, …)
    1. if there’s a method bar where the receiver type (the type of self in the method) matches U exactly , use it (a “by value method”)
    2. otherwise, add one auto-ref (take & or &mut of the receiver), and, if some method’s receiver matches &U, use it (an “autorefd method”)

Notably, everything considers the “receiver type” of the method, not the Self type of the trait, i.e. impl ... for Foo { fn method(&self) {} } thinks about &Foo when matching the method, and fn method2(&mut self) would think about &mut Foo when matching.

It is an error if there’s ever multiple trait methods valid in the inner steps (that is, there can be only be zero or one trait methods valid in each of 1. or 2., but there can be one valid for each: the one from 1 will be taken first), and inherent methods take precedence over trait ones. It’s also an error if we get to the end of the loop without finding anything that matches. It is also an error to have recursive Deref implementations, which make the loop infinite (they’ll hit the “recursion limit”).

These rules seem to do-what-I-mean in most circumstances, although having the ability to write the unambiguous FQS form is very useful in some edge cases, and for sensible error messages for macro-generated code.

Only one auto-reference is added because

  • if there was no bound, things get bad/slow, since every type can have an arbitrary number of references taken
  • taking one reference &foo retains a strong connection to foo (it is the address of foo itself), but taking more starts to lose it: &&foo is the address of some temporary variable on the stack that stores &foo.

Examples

Suppose we have a call foo.refm(), if foo has type:

  • X, then we start with U = X, refm has receiver type &..., so step 1 doesn’t match, taking an auto-ref gives us &X, and this does match (with Self = X), so the call is RefM::refm(&foo)
  • &X, starts with U = &X, which matches &self in the first step (with Self = X), and so the call is RefM::refm(foo)
  • &&&&&X, this doesn’t match either step (the trait isn’t implemented for &&&&X or &&&&&X), so we dereference once to get U = &&&&X, which matches 1 (with Self = &&&X) and the call is RefM::refm(*foo)
  • Z, doesn’t match either step so it is dereferenced once, to get Y, which also doesn’t match, so it’s dereferenced again, to get X, which doesn’t match 1, but does match after autorefing, so the call is RefM::refm(&**foo).
  • &&A, the 1. doesn’t match and neither does 2. since the trait is not implemented for &A (for 1) or &&A (for 2), so it is dereferenced to &A, which matches 1., with Self = A

Suppose we have foo.m(), and that A isn’t Copy, if foo has type:

  • A, then U = A matches self directly so the call is M::m(foo) with Self = A
  • &A, then 1. doesn’t match, and neither does 2. (neither &A nor &&A implement the trait), so it is dereferenced to A, which does match, but M::m(*foo) requires taking A by value and hence moving out of foo, hence the error.
  • &&A, 1. doesn’t match, but autorefing gives &&&A, which does match, so the call is M::m(&foo) with Self = &&&A.

(This answer is based on the code, and is reasonably close to the (slightly outdated) README. Niko Matsakis, the main author of this part of the compiler/language, also glanced over this answer.)

More Related Contents:

  1. Why can’t I store a value and a reference to that value in the same struct?
  2. Why does linking lifetimes matter only with mutable references?
  3. Why do I get “does not live long enough” in a return value?
  4. How can I conditionally provide a default reference without performing unnecessary computation when it isn’t used?
  5. What is the correct way to return an Iterator (or any other trait)?
  6. Temporarily move out of borrowed content
  7. Initialize a large, fixed-size array with non-Copy types
  8. Sending trait objects between threads in Rust
  9. Why would I implement methods on a trait instead of as part of the trait?
  10. How to initialize struct fields which reference each other
  11. “Expected fn item, found a different fn item” when working with function pointers
  12. How do you unwrap a Result on Ok or return from the function on Err?
  13. What does “mismatched types: expected `()`” mean when using an if expression?
  14. How do I read the entire body of a Tokio-based Hyper request?
  15. How can I downcast from Box to a trait object type?
  16. How do I ‘pass down’ feature flags to subdependencies in Cargo?
  17. How does Rust pattern matching determine if the bound variable will be a reference or a value?
  18. Using generic trait methods like .into() when type inference is impossible
  19. What is a crate attribute and where do I add it?
  20. Parameter type may not live long enough?
  21. How to model complex recursive data structures (graphs)?
  22. Why can’t I reuse a &mut reference after passing it to a function that accepts a generic type?
  23. print! macro not executed until pressing Enter
  24. How can I define an async method in a trait?
  25. How do I specify the linker path in Rust?
  26. How to quiet a warning for a single statement in Rust?
  27. Is there an elegant solution to modifying a structure while iterating?
  28. How do I cope with lazy iterators?
  29. Can a struct containing a raw pointer implement Send and be FFI safe?
  30. Lazy sequence generation in Rust

Leave a Comment