[ 2024-04-29; Reflector poll ]

Set priority to 2 after reflector poll and send to SG1.

As a result of Core DR 2094 (concerning triviality of volatile-qualified subobjects), is_trivially_copyable_v<volatile int> is now true, which means that `volatile int` is a valid type for `std::atomic`.

Libstdc++ and libc++ can't actually compile that type though, and that seems very sensible to me.

Even worse is that std::atomic<volatile int> will not select the specialization for `int`, because that is clearly specified by [atomics.types.int] to only be for cv-unqualified types. [atomics.types.float] also says it's only for cv-unqualified floating-point types. And [atomics.types.pointer] will only match cv-unqualified pointer types. This means that even when std::atomic<volatile int> compiles (as with MSVC) you can't use members like `fetch_add` because that only exists on the specialization, not the primary template.

Should we add something to `std::atomic` to make it not valid again, as was the case (and presumably the original intent) before CWG DR 2094?

A similar question exists for std::atomic_ref<volatile int> although there are apparently valid uses for that type. However, the `atomic_ref` specializations for integers, floats, and pointers are only for cv-unqualified types, so it doesn't work usefully. For `atomic_ref` we might want to allow `volatile`-qualified types and make the specializations match them.