Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14? Not sure about backporting further given the original fix seems
harmless.
-- >8 --
It turns out the reason the behavior of this testcase changed after CWG
2369 is because validity of the substituted return type is now checked
later, after constraints. So a more reliable workaround for this issue
is to add a constraint to check the validity of the return type earlier,
restoring the pre-CWG 2369 semantics.
PR libstdc++/104606
libstdc++-v3/ChangeLog:
* include/std/optional (operator<=>): Revert r14-9771 change.
Add constraint checking the validity of the return type
compare_three_way_result_t before the three_way_comparable_with
constraint.
---
libstdc++-v3/include/std/optional | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/optional
b/libstdc++-v3/include/std/optional
index 832dc6fd84b..a616dc07b10 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -1685,7 +1685,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template<typename _Tp, typename _Up>
requires (!__is_derived_from_optional<_Up>)
- && three_way_comparable_with<_Up, _Tp>
+ && requires { typename compare_three_way_result_t<_Tp, _Up>; }
+ && three_way_comparable_with<_Tp, _Up>
constexpr compare_three_way_result_t<_Tp, _Up>
operator<=> [[nodiscard]] (const optional<_Tp>& __x, const _Up& __v)
{ return bool(__x) ? *__x <=> __v : strong_ordering::less; }
--
2.49.0.rc0
