Another deref question: the priority of deref coercion

[zylthinking]

    fn main3() {
        use std::ops::Deref;
        let r = &&1;

        // i32
        let x = *(r.deref());
        // &i32
        let y = *r;
    }

Like code above; why the x, y have different types?

[alice]

The r.deref() call returns a &i32, so if you dereference that, you get an i32.

[zylthinking]

@alice

The r.deref() call returns a &i32 , so if you dereference that, you get an i32 .

The question is why impl Deref for &i32 is selected to execute.
And why impl Deref for &&i32 is selected for let y = *r

[alice]

There is no deref coercion at all in the let y = *r line.

[zylthinking]

But it satisfied

impl<T: ?Sized> Deref for &T {
    type Target = T;

    #[rustc_diagnostic_item = "noop_method_deref"]
    fn deref(&self) -> &T {
        *self
    }
}

and the book says:

When we entered *y in Listing 15-9, behind the scenes Rust actually ran this code:

*(y.deref())

Rust substitutes the * operator with a call to the deref method and then a plain dereference so we don’t have to think about whether or not we need to call the deref method. This Rust feature lets us write code that functions identically whether we have a regular reference or a type that implements Deref .

The reason the deref method returns a reference to a value, and that the plain dereference outside the parentheses in *(y.deref()) is still necessary, is the ownership system. If the deref method returned the value directly instead of a reference to the value, the value would be moved out of self . We don’t want to take ownership of the inner value inside MyBox<T> in this case or in most cases where we use the dereference operator.

[alice]

That substitution doesn't happen for references because references are special. Notice that the deref function you listed is actually implemented as *self, which would be an infinite recursive loop if the compiler actually made that substitution.

Anyway, I see why you are confused. There's still a question of why our *(r.deref()) example behaves differently from the *(y.deref()) in the book. To be explicit, the exact choices are the following:

let x = *Deref::deref(r);

*Deref::deref(&y)

The compiler prefers to call the method that does not involve adding an & in front to calling the method that involves adding an & in front. However in the example in the book, there's no version of Deref that takes the box by-value, so it can't make that choice there.