Issue 3508: atomic_ref is not well-specified (original) (raw)

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

3508. atomic_ref<_cv_ T> is not well-specified

Section: 32.5.7.1 [atomics.ref.generic.general] Status: Resolved Submitter: Casey Carter Opened: 2020-12-02 Last modified: 2025-10-14

Priority: 2

View all issues with Resolved status.

Discussion:

atomic_ref<T> requires only that its template parameter T is trivially copyable, which is not sufficient to implement many of the class template's member functions. Consider, for example:

int main() { static const int x = 42; std::atomic_ref meow{x}; meow.store(0); return meow.load(); }

Since const int is trivially copyable, this is a well-formed C++20 program that returns 0. That said, the store call that mutates the value of a constant object is (a) not implementable with library technology, and (b) pure madness that violates the language semantics. atomic_ref::storeshould presumably require is_copy_assignable_v<T>, and other operations need to have their requirements audited as well. (Related: LWG 3012(i) made similar changes to atomic.)

As a related issue, volatile atomic<T> recently had its member functions deprecated when they are not lock-free. Presumably atomic_ref<volatile T> should require that atomic operations onT be lock-free for consistency.

Jonathan:

The last point is related to LWG 3417(i) (another case where we screwed up the volatiledeprecations).

[2020-12-19; Reflector prioritization]

Set priority to 2 during reflector discussions.

[2024-06; Related to issue 4069(i).]

[St. Louis 2024-06-28; SG1 feedback]

SG1 forwarded P3323R0 to LEWG to resolve LWG issues3508(i) and 4069(i).

[2025-02-07 Status changed: Open → Resolved.]

Resolved by P3323R1 in Wrocław.

Proposed resolution: