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

[tgross35]

I don't think there's too much debate about anything here, so I opened #108419 to stabilize it

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se 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

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. 🔔

[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.

This will be merged soon.