Change:
use std::mem::drop; #[test] <ins> fn smoketest_unsafe_cell() { let mut x = UnsafeCell::new(10); let ref_mut = &mut x; unsafe { // The asserts are repeated in order to ensure that `get()` // is non-mutating. assert_eq!(*ref_mut.get(), 10); assert_eq!(*ref_mut.get(), 10); *ref_mut.get_mut() += 5; assert_eq!(*ref_mut.get(), 15); assert_eq!(*ref_mut.get(), 15); assert_eq!(x.into_inner(), 15); } } #[test] fn unsafe_cell_raw_get() { let x = UnsafeCell::new(10); let ptr = &x as *const UnsafeCell<i32>; unsafe { // The asserts are repeated in order to ensure that `raw_get()` // is non-mutating. assert_eq!(*UnsafeCell::raw_get(ptr), 10); assert_eq!(*UnsafeCell::raw_get(ptr), 10); *UnsafeCell::raw_get(ptr) += 5; assert_eq!(*UnsafeCell::raw_get(ptr), 15); assert_eq!(*UnsafeCell::raw_get(ptr), 15); assert_eq!(x.into_inner(), 15); } } #[test] </ins> fn smoketest_cell() { let x = Cell::new(10); assert_eq!(x, Cell::new(10));

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 :-)