[libcxx-commits] [PATCH] D59029: [libc++] Do not specify the underlying type of memory_order

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

Actually, the only `static_assert` I can conceive here would be this:

  #if _LIBCPP_STD_VER > 17
  
  typedef enum __cpp17_memory_order {
    __cpp17_memory_order_relaxed, __cpp17_memory_order_consume, __cpp17_memory_order_acquire,
    __cpp17_memory_order_release, __cpp17_memory_order_acq_rel, __cpp17_memory_order_seq_cst
  } __cpp17_memory_order;
  
  enum class memory_order {
    relaxed, consume, acquire, release, acq_rel, seq_cst
  };
  
  static_assert(is_same<underlying_type<__cpp17_memory_order>::type, 
                        underlying_type<memory_order>::type>::value,
                "The C++20 and C++17 memory order enumerations should have the same underlying type");
  
  #else
  
  typedef enum memory_order {
    memory_order_relaxed, memory_order_consume, memory_order_acquire,
    memory_order_release, memory_order_acq_rel, memory_order_seq_cst
  } memory_order;
  
  #endif // _LIBCPP_STD_VER > 17

TBH, I don't think there's a lot of value in this. However, if we care that much about this, then I'd probably revert my previous position of not back-porting the enum class behavior to pre-C++20. IOW, instead of adding this complexity, I'd just make the definition the same in C++17 and C++20, and we'd be non-conforming in C++17.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59029/new/

https://reviews.llvm.org/D59029