Can't coerce &mut &mut T to *mut *mut T

[Boddlnagg]

The title already says it, but as an illustrating example you can have a look at https://is.gd/4jWY3m.
Since &mut T can be implicitly converted to *mut T, I wondered whether there's a reason that it doesn't work for &mut &mut T (besides "no one has implemented it" 😄 ). @mbrubeck pointed out that this might be #18602 (in IRC).

The example code also illustrates a somewhat unexpected failure of type inference, which might be worth filing as a separate issue.

[eefriedman]

Hmm... take the following:

    let mut result = SmartPtr(std::ptr::null_mut());
    let x : &mut &mut _ = &mut &mut *result;
    let x : *mut &mut _ = x;
    let x: *mut *mut _ = x;
    make_foo(x); 

Rust will currently complain about mismatched types for the second coercion. It's not clear such a coercion should exist: it's like converting a *mut i8 to a *mut u8.

[TimNN]

@eefriedman Note that first coercing to &mut *mut instead of *mut &mut seems to work (playpen).

[eefriedman]

@TimNN Your testcase is constructing a SmartPtr<*mut Foo>, not a SmartPtr<Foo>.

[TimNN]

Ah, thanks for pointing that out.

[Boddlnagg]

@eefriedman In don't know if I understand your point, but if you argue that such a coercion should not exist because it might be unsafe, the line make_foo(&mut (&mut *result as *mut _)); in my original example shows that this conversion is already possible in safe code.

[petrochenkov]

It's not clear such a coercion should exist: it's like converting a *mut i8 to a *mut u8.

Heh, C++ has special rules for multi-level pointer conversions exactly to prevent these kinds of type unsafeties: http://en.cppreference.com/w/cpp/language/implicit_conversion#Qualification_conversions
"More qualified" relations can be translated to Rust's &mut T -> *mut T/&T -> *const T/*mut T -> *const T relations.

[eefriedman]

@Boddlnagg make_foo(&mut (&mut *result as *mut _)); isn't doing the same thing: the outer &mut is actually constructing a temporary, so you end up with an &mut *mut Foo (as opposed to a *mut &mut Foo).

Also, safety isn't really relevant; we allow arbitrary explicit pointer casts anyway.

[eefriedman]

Oh, wait, I see, you expect the original make_foo(&mut &mut *result) to interpreted as &mut *mut Foo, and then converted from there to *mut *mut Foo. That makes sense.

[eddyb]

I think this would work if borrow expressions would take into account that they might get coerced later and pass down the T from *mut T (where T = *mut Foo here), instead of only working for &mut T.

[steveklabnik]

Triage: this still reproduces.

[Dylan-DPC]

Closing this as the bug is fixed and playground link above works for all editions.

[Boddlnagg]

The playground link had the problematic line commented out:

make_foo(&mut &mut *result); // mismatched types: expected `*mut *mut Foo`, found `&mut &mut _`

It still gives a compile error:

error[[E0308]](https://doc.rust-lang.org/nightly/error_codes/E0308.html): mismatched types
  --> src/main.rs:31:14
   |
31 |     make_foo(&mut &mut *result); // mismatched types: expected `*mut *mut Foo`, found `&mut &mut _`
   |     -------- ^^^^^^^^^^^^^^^^^ expected `*mut *mut Foo`, found `&mut &mut _`
   |     |
   |     arguments to this function are incorrect
   |
   = note:    expected raw pointer `*mut *mut Foo`
           found mutable reference `&mut &mut _`

[Dylan-DPC]

oops my bad then

[workingjubilee]

This idea has been suggested.

A T-compiler member has pointed out that other languages apply rules to restrain pointer coercion, specifically because multi-level pointer coercion is prone to being a bit of a footgun. Not quite "this is a bad idea", but despite the simplicity of the proposal, it deserves being treated with caution.

There is no strong argument that this is a bug because it is consistent, if annoying.

Legalizing this behavior with narrow cases seems permissible, but amounts to a new language feature design request. Transitive coercions, as part of the revised coercion rules, are closed as requiring new proposals.

Accordingly, I think this should also be closed... but not before documenting the current behavior in the form of a regression test.