[libcxx-commits] [libcxx] [libc++] Implement P2830R10: Standardized Constexpr Type Ordering (PR #216616)

[Nikolas Klauser via libcxx-commits]

================
@@ -0,0 +1,40 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___COMPARE_TYPE_ORDER
+#define _LIBCPP___COMPARE_TYPE_ORDER
+
+#include <__compare/ordering.h>
+#include <__config>
+
+#ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 26 && __has_builtin(__builtin_type_order)
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+// [compare.type], type ordering
+template <class _Tp, class _Up>
+struct _LIBCPP_NO_SPECIALIZATIONS type_order {
+  static constexpr strong_ordering value = __builtin_type_order(_Tp, _Up);
+  using value_type                       = strong_ordering;
+
+  _LIBCPP_HIDE_FROM_ABI constexpr operator value_type() const noexcept { return value; }
----------------
philnik777 wrote:

> Conversion operators cannot be static.

Fair.

> As for the call operator - I think that would be sensible, but the wording doesn't say `static` here. We don't make `operator()` static for `integral_constant` either.

`operator()` couldn't be `static` when `integral_constant` was implemented either. We might want to consider making it `static` now though.

https://github.com/llvm/llvm-project/pull/216616