Change:
/// assert_eq!(uc.into_inner(), 5); /// ``` #[inline(always)] <del> #[unstable(feature = "unsafe_cell_raw_get", issue = "66358")] </del> <ins> #[stable(feature = "unsafe_cell_raw_get", since = "1.56.0")] </ins> pub const fn raw_get(this: *const Self) -> *mut T { // We can just cast the pointer from `UnsafeCell<T>` to `T` because of // #[repr(transparent)]. This exploits libstd's special status, there is

Discussion:
a raw pointer variant of . Unresolved issues: [ ] This definitely wants to be a method -- is so much more readable than . Also see
Would it work to have it be a method by adding additional implementations on ?
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 and it sounded like the associated function would be forward compatible with any future implementation as a method, unless I misunderstood.
that's up to 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 receiver type these days? A lot of time has passed since
Cc (I had a typo in the ping above, don't know if GH sends notifications for pings in edits)
fcp merge I am proposing to stabilize the UnsafeCell::raw_get associated function as currently implemented in nightly: At the call site, use of this associated function looks like: In response to the unresolved issue that method syntax would be cleaner at the call site, apparently this use case is already covered by We can backward compatibly replace with in a future release. Demo:
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [x] 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
To me, it feels surprising that the name is . I would expect , similarly to ’into_raw’. Am I missing a reason why this needs to be inconsistent?
I don't have a strong opinion on it. But I suppose the 'raw' applies to the , 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 seems fine to me. Any opinions on vs ?
Spitballing other names: Not a huge fan of any of them (including 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.
One more thing: we have in NonNull: Seems better to use one of ptr or raw, not both.
The final comment period, with a disposition to merge, as per the , 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.
Note that the existing also gives a and does not have in the name. (The only difference is that takes a instead of a .) Doesn't look like it. As pointed out during the libs api meeting last week: seems like a good convention.
Aha, now that clicked for me! What we are emphasizing here is that self is a raw pointer: vs . 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 :-)