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.

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

Section: [atomics.ref.generic.general] Status: New Submitter: Casey Carter Opened: 2020-12-02 Last modified: 2024-06-10

Priority: 2

View all issues with New status.


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<const int> meow{x};;
  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::store should presumably require is_copy_assignable_v<T>, and other operations need to have their requirements audited as well. (Related: LWG 3012 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 on T be lock-free for consistency.


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

[2020-12-19; Reflector prioritization]

Set priority to 2 during reflector discussions.

[2024-06; Related to issue 4069.]

Proposed resolution: