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: 31.7.1 [atomics.ref.generic.general] Status: New Submitter: Casey Carter Opened: 2020-12-02 Last modified: 2020-12-19

Priority: 2

View all issues with New 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<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).

[2020-12-19; Reflector prioritization]

Set priority to 2 during reflector discussions.

Proposed resolution: