This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4571. Disallow specializing std::atomic and std::atomic_ref

Section: 32.5.7.1 [atomics.ref.generic.general], 32.5.8.1 [atomics.types.generic.general] Status: New Submitter: Jiang An Opened: 2026-04-17 Last modified: 2026-04-17

Priority: Not Prioritized

View all other issues in [atomics.ref.generic.general].

View all issues with New status.

Discussion:

Currently, specializations of std::atomic and std::atomic_ref for non-bool integer types, floating-point types, and pointer types are specified as if they're full specializations. However, implementations generally merge these specializations in quite arbitrary ways.

As for 2026-04:

• MSVC STL provides all atomic and atomic_ref specializations in primary templates.

• libc++ merges specializations for integer types with the atomic primary template, and provides atomic_ref specializations for arithmetic types in many partial specializations.

• libstdc++ provides all atomic_ref specializations in the primary template, while providing atomic full specializations like the standard wording.

The divergence among implementations and standard wording is observable if it's allowed to specialize atomic or atomic_ref. Also, it's already noted in cplusplus/draft#7556 that it's unimplementable to provide full specializations for all atomic_ref<pointer-type>.

On the other hand, it's desired that _Atomic(T) behaves as consistently as possible in C and C++ (per 32.5.12 [stdatomic.h.syn]/4). This is possible unachievable if atomic<T> is a program-defined specialization.

Given it's unclear whether program-defined specializations of atomic and atomic_ref make sense, and there're some potential drawbacks allowing them, perhaps it would be better to disallow specializing atomic and atomic_ref.

Proposed resolution:

This wording is relative to N5032.

1. Modify 32.5.1 [atomics.general] as indicated:

   -1- Subclause 32.5 [atomics] describes components for fine-grained atomic access. This access is provided via operations on atomic objects.

   -?- [Note ?: Although some specializations of atomic and atomic_ref are specified as explicit or partial specializations, the implementation can merge these specializations in an unspecified way, because a program-defined specialization is invalid. — end note]

2. Modify 32.5.7.1 [atomics.ref.generic.general] as indicated:

   -5- The program is ill-formed if is_always_lock_free is false and is_volatile_v<T> is true.

   -?- The program is ill-formed, no diagnostic required, if it declares an explicit or partial specialization of atomic_ref.

3. Modify 32.5.8.1 [atomics.types.generic.general] as indicated:

   -1- The template argument for T shall meet the Cpp17CopyConstructible and Cpp17CopyAssignable requirements. The program is ill-formed if any of

   […]

   is false.

   -?- The program is ill-formed, no diagnostic required, if it declares an explicit or partial specialization of atomic.