Tracking Issue for `unsafe_cell_get_mut`

[danielhenrymantilla]

This is a tracking issue for adding the fn get_mut (self: &mut UnsafeCell<T>) -> &mut T method.
The feature gate for the issue is #![feature(unsafe_cell_get_mut)].

History

• Implement the RFC: Add non-unsafe .get_mut() for Unsafecell #76936
• Stabilization PR: Stabilize unsafe_cell_get_mut #79485

Unresolved Questions

None

[danielhenrymantilla]

This is small enough not to need an RFC, it seems, so it can go directly to the FCP: cc @RalfJung & the rest of T-Lang T-libs

[RalfJung]

FCP will happen when we move towards stabilization. We usually wait a few release cycles before doing that. Also this is T-libs territory, I don't think any language rules are being changed here (just clarified).

---

@rust-lang/libs this is about adding UnsafeCell::get_mut, a method to safely go from &mut UnsafeCell<T> to &mut T. This is a sound operation on its own, and all standard library interior mutable types have an equivalent function in their API surface.

However, there is a theoretical scenario where this can cause unsoundness in existing libraries: if a user-defined library, for some reason, exposes an &mut UnsafeCell<T> to a client and relied on the fact that there was no way for safe clients to do anything with that reference. I do not know why a library would do this, but I seem to recall this concern being brought up before when changes to UnsafeCell are proposed. In this sense, the change is not backwards compatible, but only if a library relied on UnsafeCell guarantees that I do not think we ever made.

[danielhenrymantilla]

if a user-defined library, for some reason, exposes an &mut UnsafeCell to a client and relied on the fact that there was no way for safe clients to do anything with that reference

Good point, although the only way they could rely on "not being to do anything with that reference" is if they (ab)used the fact that there was no other instance of type T around (singleton pattern, or through a highly generic API relying on "type-level generativity").

Otherwise it is possible to:

fn mutate<T> (p: &mut UnsafeCell<T>, value: T)
{
    *p = value.into();
}

and more generally, we can currently write:

fn with_mut<T, R> (
    p: &'_ mut UnsafeCell<T>,
    f: impl FnOnce(&'_ mut T) -> R,
) -> R
where
    T : Default,
{
    let mut prev = mem::take(p).into_inner();
    // defer putting the value back
    let mut prev = ::scopeguard::guard(prev, |it| *p = it.into());
    f(&mut *prev)
}

• which performs a read-write of the payload when entering, and a write (+ drop in place) when leaving

[RalfJung]

Ah right, you can just overwrite what is in an &mut UnsafeCell<T>. Yeah that makes it even less likely that this would be a problem.

[m-ou-se]

Stabilization PR: #79485