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

Resolved by P3323R1 in Wrocław.

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

SG1 forwarded P3323R0 to LEWG to resolve LWG issues 3508 and 4069.

[ 2024-06; Related to issue 4069. ]

[ 2020-12-19; Reflector prioritization ]

Set priority to 2 during reflector discussions.

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};
  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::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.

Jonathan:

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