Tracking issue for UnsafeCell::raw_get

[RalfJung]

#66248 added a raw pointer variant of UnsafeCell::get.

Unresolved issues:

• This definitely wants to be a method -- m.as_ptr().raw_get().write(5) is so much more readable than UnsafeCell::raw_get(m.as_ptr()).write(5). Also see add raw ptr variant of UnsafeCell::get #66248 (comment).

[programmerjake]

Would it work to have it be a method by adding additional implementations on * mut/const UnsafeCell<T>?

impl<T: ?Sized> *mut UnsafeCell<T> {
    pub const fn raw_get(self) -> *mut T {
        UnsafeCell::raw_get(self)
    }
}

impl<T: ?Sized> *const UnsafeCell<T> {
    pub const fn raw_get(self) -> *mut T {
        UnsafeCell::raw_get(self)
    }
}

[DavidVonDerau]

@RalfJung Is there an option to stabilize the associated function first and open a separate tracking issue for the method impl? I read the discussion at #66248 (comment) and it sounded like the associated function would be forward compatible with any future implementation as a method, unless I misunderstood.

[RalfJung]

@DavidVonDerau that's up to @rust-lang/libs, really -- I don't know if this is definitely forward compatible or not (though it seems plausible).

Also, don't have have stable functions with *const Self receiver type these days? A lot of time has passed since #66248.

[RalfJung]

Cc @rust-lang/libs (I had a typo in the ping above, don't know if GH sends notifications for pings in edits)

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

I am proposing to stabilize the UnsafeCell::raw_get associated function as currently implemented in nightly:

impl<T: ?Sized> UnsafeCell<T> {
     pub const fn raw_get(this: *const Self) -> *mut T;
}

At the call site, use of this associated function looks like:

let m = MaybeUninit::<UnsafeCell<i32>>::uninit();
unsafe { UnsafeCell::raw_get(m.as_ptr()).write(5); }
let uc = unsafe { m.assume_init() };

In response to the unresolved issue that method syntax would be cleaner at the call site, apparently this use case is already covered by #44874. We can backward compatibly replace this: *const Self with self: *const Self in a future release.

Demo:

#![feature(arbitrary_self_types)]

use std::mem::MaybeUninit;

struct UnsafeCell;
struct T;

impl UnsafeCell {
    fn raw_get(self: *const Self) -> *mut T { unimplemented!() }
}

fn main() {
    let m = MaybeUninit::<UnsafeCell>::uninit();
    unsafe { m.as_ptr().raw_get().write(T) }
    let _uc = unsafe { m.assume_init() };
}

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[matklad]

To me, it feels surprising that the name is raw_get. I would expect get_raw, similarly to get_mut|from_raw|’into_raw’. Am I missing a reason why this needs to be inconsistent?

[m-ou-se]

I don't have a strong opinion on it. But I suppose the 'raw' applies to the UnsafeCell, not to the return type. So the 'raw' applies to the input rather than the return type: "get from a raw thing" instead of "get a raw thing". So raw_get seems fine to me.

@rust-lang/libs-api Any opinions on raw_get vs get_raw?

[BurntSushi]

Spitballing other names:

• get_mut
• mut_from_raw
• raw_to_mut
• raw_get_mut

Not a huge fan of any of them (including raw_get to be honest). Do we have other instances of self (or self-like) types being raw pointers? Maybe the problem is that we just don't have an established convention for them yet.

[matklad]

One more thing: we have get_ptr in NonNull: https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.as_ptr. Seems better to use one of ptr or raw, not both.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[m-ou-se]

Spitballing other names

Note that the existing UnsafeCell::get also gives a *mut T and does not have mut in the name. (The only difference is that raw_get takes a *const Self instead of a &Self.)

Do we have other instances of self (or self-like) types being raw pointers?

Doesn't look like it.

Maybe the problem is that we just don't have an established convention for them yet.

As @dtolnay pointed out during the libs api meeting last week: raw_ seems like a good convention.

[matklad]

Aha, now that clicked for me! What we are emphasizing here is that self is a raw pointer: &Self vs *const Self. Which admittedly is exactly what the docs say, and what m-ou-se pointed out in the comment five days ago, seems like I just needed to read this n+1 time :-)