Tracking issue for atomic_mut_ptr

[KodrAus]

This is a tracking issue foratomic_mut_ptr.

Public API

impl AtomicBool {
    pub const fn as_ptr(&self) -> *mut bool;
}

impl AtomicI32 {
    pub const fn as_ptr(&self) -> *mut i32;
}

// … etc.

impl<T> AtomicPtr<T> {
    pub const fn as_ptr(&self) -> *mut *mut T;
}

Steps / History

• Implementation: Atomic as_mut_ptr #66705
• Add to AtomicPtr too: Add AtomicPtr::as_mut_ptr #106762
• Make const: Mark 'atomic_mut_ptr' methods const #107706
• Rename to as_ptr: Rename atomic 'as_mut_ptr' to 'as_ptr' to match Cell (ref #66893)  #107736
• Final comment period (FCP)
• Stabilization PR

[nox]

Any use of the returned raw pointer requires an unsafe block and still has to uphold the same restriction: operations on it must be atomic.

I'm not sure this is phrased as best as it could in the documentation, in the sense that callers are definitely allowed to do non-atomic accesses to the underlying value, but they must do so only if they can guarantee that absolutely no other thread will observe a non-atomic access. Does that make sense?

[m-ou-se]

This should probably also be added to AtomicPtr, for consistency between the Atomic* types.

[tgross35]

@KodrAus are there any concerns about stabilizing this feature? If not, could we go ahead with the stabilization PR?

[tgross35]

Actually I have one addition - this could be const with no problem, which would make it easier to use with FFI statics. (opened #107706 for this)

[m-ou-se]

I'm wondering if it should just be as_ptr instead of as_mut_ptr. Cell<T> also has a as_ptr() that returns a *mut T.

[tgross35]

Yeah, that's a good point. I don't think there are many cases where a separate as_ptr and as_mut_ptr make sense, since you'd always prefer to just .load(...) the data if you don't need to change it.

Would this naming change require a FCP?

Edit: created #107736 to discuss