`mut` restrictions have inconsistent behavior with &mut fields

[theemathas]

The mut restriction feature is inconsistent on whether mutating through a &mut T field counts as mutating the field or not. I'm not sure what the desired behavior is here.

#![feature(mut_restriction)]

mod module {
    pub struct Thing(pub mut(self) &'static mut u8);
}

use module::Thing;

// errors
pub fn fails(x: Thing) {
    *x.0 = 1;
}

// compiles
pub fn works(x: Thing) {
    let y = x.0;
    *y = 1;
}

// errors
pub fn also_fails(x: Thing) {
    let y: &mut u8 = x.0;
    *y = 1;
}

error: field `0` cannot be mutated outside `crate::module`
  --> src/lib.rs:11:5
   |
 4 |     pub struct Thing(pub mut(self) &'static mut u8);
   |                          --------- field restricted here
...
11 |     *x.0 = 1;
   |     ^^^^^^^^

error: field `0` cannot be mutated outside `crate::module`
  --> src/lib.rs:22:22
   |
 4 |     pub struct Thing(pub mut(self) &'static mut u8);
   |                          --------- field restricted here
...
22 |     let y: &mut u8 = x.0;
   |                      ^^^

error: could not compile `playground` (lib) due to 2 previous errors

Meta

Reproducible on the playground with version 1.99.0-nightly (2026-08-11 3d6c19bb9ab4798ecfb2)

[Urgau]

I think this is the expected behavior. In your example let y = x.0; moves the field out of Thing which makes x no longer usable and as such keeps the invariants of Thing.

cc @jhpratt

[jhpratt]

I'll have to check reborrowing and whatnot when I'm on my laptop, as I'm surprised the third fails. The first and second are definitely correct. As Urgau said, the field is moved and no longer part of the struct where the restriction is in place.

It's worth noting that the restriction "simply" reuses what's considered a mutable use in the compiler — a definition that has existed for years. So my suspicion is this is completely correct and there's something not immediately evident to me for the third example.