Title
P0439R0 changed the value category of memory order constants
Status
nad
Section
[atomics.order]
Submitter
Jiang An

Created on 2023-10-18.00:00:00 last changed 1 week ago

Messages

Date: 2026-08-21.17:08:58

Proposed resolution:

This wording is relative to N4964.

  1. Modify [atomics.syn], header <atomic> synopsis, as indicated:

    namespace std {
      // [atomics.order], order and consistency
      enum class memory_order : unspecified;                        // freestanding
      inline constexpr memory_order memory_order_relaxed = memory_order::relaxedusing memory_order::memory_order_relaxed; // freestanding
      inline constexpr memory_order memory_order_consume = memory_order::consumeusing memory_order::memory_order_consume; // freestanding
      inline constexpr memory_order memory_order_acquire = memory_order::acquireusing memory_order::memory_order_acquire; // freestanding
      inline constexpr memory_order memory_order_release = memory_order::releaseusing memory_order::memory_order_release; // freestanding
      inline constexpr memory_order memory_order_acq_rel = memory_order::acq_relusing memory_order::memory_order_acq_rel; // freestanding
      inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cstusing memory_order::memory_order_seq_cst; // freestanding
      
      […]
    }
    […]
    
  2. Modify [atomics.order] as indicated:

    namespace std {
      enum class memory_order : unspecified {
        relaxed, consume, acquire, release, acq_rel, seq_cst,
        memory_order_relaxed = relaxed, memory_order_consume = consume, memory_order_acquire = acquire,
        memory_order_release = release, memory_order_acq_rel = acq_rel, memory_order_seq_cst = seq_cst
      };
    }
Date: 2026-08-21.00:00:00

[ 2026-08-21 LWG telecon; Status changed New → NAD ]

The proposed resolution would need to be rebased because `consume` has been deprecated now.

Although LWG liked the first part of the change, making the old names enumerators again rather than global objects, we did not like the second part which adds new enumerators with the old names. The cure seems worse than the disease. Having the old names be objects that can have their address taken (and can have references bound directly to them without creating a temporary) is a little unpleasant, but it doesn't really do any harm. If you want to ensure that no inline variables get emitted into your object files when you refer to those memory orders, just use the new form, i.e. the `memory_order::seq_cst` names instead of `memory_order_seq_cst`.

If we had a feature like `using memory_order::seq_cst as memory_order_seq_cst` which would allow giving a new name to the enumerator, it could be done without having to add the new enumerators to the enum.

From an implementation perspective, `using enum` is a C++20 feature so would require compiler extensions to make it available in C++17 modes, or the defect would still be present in C++17 modes and only fixed for C++20 and later.

Date: 2023-11-15.00:00:00

[ 2023-11-02; Reflector poll ]

Set priority to 4 after reflector poll.

Date: 2023-10-18.00:00:00

P0439R0 made std::memory_order an scoped enumeration type. However, it also changed former enumerators (std::memory_order_seq_cst) to constexpr variables.

It is unclear the additional change is intended while it presumably bothered nobody in practice. Given there is using enum (P1099R5) in C++20, it may be better to keep these constants being prvalues.

History
Date User Action Args
2026-08-21 17:08:58adminsetmessages: + msg16557
2026-08-21 17:08:58adminsetstatus: new -> nad
2023-11-03 18:08:28adminsetmessages: + msg13811
2023-10-21 10:13:56adminsetmessages: + msg13761
2023-10-18 00:00:00admincreate