Confusing MaybeUninit documentation

[DutchGhost]

The as_ptr method on a MaybeUninit<T> perhaps could use some better wording, or at least an example.

The docs say: "Writing to memory that this pointer (non-transitively) points to is undefined behavior (except inside an UnsafeCell)."

Its unclear whether that means &MaybeUninit<UnsafeCell<T>> -> *const UnsafeCell<T> -> *mut T is okey, or that &UnsafeCell<MaybeUninit<T>> -> *mut MaybeUninit<T> -> *mut T is okey, if the resulting mutable pointer is written to.

Perhaps adding a little example of which of the two is okey, (or perhaps both) would help.

[Centril]

cc @RalfJung

[RalfJung]

Yeah this can probably be improved. Note that quite a few as_ptr methods have a remark like this, e.g. also see slice::as_ptr.

I am not sure what the best place for this is though; there are lots of examples one could wonder about and we probably don't want to list all of them in each as_ptr method. It would probably make more sense to have a chapter on interior mutability in the Referene or the Nomicon, and link there.

To be clear, &MaybeUninit<UnsafeCell<T>> -> *const UnsafeCell<T> -> *mut T is okay because the UnsafeCell is present in the shared reference already. &UnsafeCell<MaybeUninit<T>> -> *mut MaybeUninit<T> -> *mut T does not even really have anything to do with MaybeUninit, that's just using UnsafeCell directly from what I can see.

[joshlf]

Ran into a similar issue with slice::from_raw_parts. IIUC, the requirement is that, if mutation happens, it must be the case that all code paths view the bytes that are being mutated as inside of an UnsafeCell. Ie, having an &UnsafeCell<T> and a &T pointing to the same memory location and mutating via the former is unsound. Is that right?

[hkBst]

@joshlf A &T pointing to a memory location that changes value is immediate UB, IIUC, which includes your example.