[PATCH] D59029: [libc++] Do not specify the underlying type of memory_order
Louis Dionne via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 6 09:34:15 PST 2019
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
More information about the llvm-commits
mailing list