unsafe { &mut *x } vs &mut unsafe { *x }

[hkBst]

I tried this code:

fn main() {
    let y: &mut [bool] = &mut [false; 2];
    let x = unsafe { &mut *(y as *mut [_] as *mut [std::mem::MaybeUninit<_>]) };
    let x = &x[0].write(true);
    println!("{x}");
}

which works fine, but if you move the unsafe ever so slightly inwards, like so:

fn main() {
    let y: &mut [bool] = &mut [false; 2];
    let x = &mut unsafe { *(y as *mut [_] as *mut [std::mem::MaybeUninit<_>]) };
    let x = &x[0].write(true);
    println!("{x}");
}

you get this error output:

error[[E0161]](https://doc.rust-lang.org/stable/error_codes/E0161.html): cannot move a value of type `[MaybeUninit<bool>]`
 --> src/main.rs:3:18
  |
3 |     let x = &mut unsafe { *(y as *mut [_] as *mut [std::mem::MaybeUninit<_>]) };
  |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the size of `[MaybeUninit<bool>]` cannot be statically determined

error[[E0508]](https://doc.rust-lang.org/stable/error_codes/E0508.html): cannot move out of type `[MaybeUninit<bool>]`, a non-copy slice
 --> src/main.rs:3:27
  |
3 |     let x = &mut unsafe { *(y as *mut [_] as *mut [std::mem::MaybeUninit<_>]) };
  |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |                           |
  |                           cannot move out of here
  |                           move occurs because value has type `[MaybeUninit<bool>]`, which does not implement the `Copy` trait

Some errors have detailed explanations: E0161, E0508.
For more information about an error, try `rustc --explain E0161`.
error: could not compile `playground` (bin "playground") due to 2 previous errors

Version tested is 1.82.0 and current nightly on the playground

[WaffleLapkin]

This isn't a bug, this is expected behavior, although it might be a bit confusing. unsafe {} behaves as a normal block {} for all purposes except allowing unsafe constructs to be used inside.

So, simplified, the difference in your examples is between &mut *x and &mut { *x }, which are semantically different. In &mut *x, *x creates a place and &mut creates a reference to that place. In &mut { *x }, *x creates a place, which is then coerced to a value (block tail expression requires a value), and then the value of a block is coerced back to a place by inserting a temporary and a reference to that temporary is created.

Your second example doesn't compile because {} causes a load (aka place-to-value coercion) and unsized types can't be loaded.

All of this is confusing, because places are implicit in Rust syntax. To learn more I would recomend Ralf Jung's article about places: https://www.ralfj.de/blog/2024/08/14/places.html

I'm tagging this as a diagnostic issue, we could maybe create a diagnostic for this specific case (&mut {...}), mentioning that blocks require a value. We could also maybe report a single error, instead of two.

[hkBst]

@WaffleLapkin thanks for your explanation. Indeed it occurs also with normal blocks and given your reminder that unsafe blocks count as normal blocks, it has nothing to do with unsafe. I'll have a look at Ralf's blog, thanks for the link.

[hkBst]

Okay that blog clears everything right up, and even mentions that it is unfortunate that unsafe blocks are also implicitly blocks. So yeah, it would be good if the diagnostics could be improved.