Tracking Issue for generic `Atomic`

[CAD97]

Feature gate: #![feature(generic_atomic)]

This is a tracking issue for replacing the distinct Atomic* types with a generic Atomic<T> type. This allows using Atomic with FFI type aliases and helps clean up some API surface. Only types with existing AtomicT are usable in Atomic<T>.

Public API

// core::sync::atomic

pub struct Atomic<T: AtomicPrimitive>(/* private fields*/);

pub type AtomicI32 = Atomic<i32>; // etc

Steps / History

• ACP: ACP: Generic Atomic<T> libs-team#443
• Implement Atomic<T> as an alias to AtomicT: Create Atomic<T> type alias #130543
• Flip alias so AtomicT is an alias to Atomic<T>
• Move generic functionality from AtomicT to Atomic<_>
• Pseudo-prerequisite: Stabilize 128-bit atomics: Tracking issue for integer_atomics #99069
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Atomic<T> is soft-blocked on 128-bit atomics, because since trait implementations cannot be unstable, gating Atomic<i128> separately from Atomic<i32> isn't possible.
  • If necessary, AtomicI128 could instead name Atomic<Wrapper<i128>> for some unstable name Wrapper until 128-bit atomics are stable, to prevent Atomic<i128> from being usable from stable earlier than intended.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[cynecx]

Would/could this allow Atomic<(*const (), u64)>?

[CAD97]

Not in the initial implementation tracked here, which does not aim to extend the set of types usable atomically yet. In the future, yes, this moves us into the direction of being able to support additional atomic types in the API.

[RalfJung]

From the ACP

impl<T> Unpin for Atomic<T> {}

This is surprising to me, why does this not propagate the Unpinness of T?

[CAD97]

Why not propagate Unpin

In this case, because I was overly terse laying out the API in the ACP, apparently. Both the NonZero code I was basing general structure off of and my local sketch do actually bound the autotrait impls on T: AutoTrait.

But also,

• The initial set of allowed types are all Unpin.
• It seems fundamentally impossible to use the atomic load/store/swap API with pinned data.