On Thu, 27 Feb 2025 at 21:03, Patrick Palka <ppa...@redhat.com> wrote:
>
> 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.
Yeah, trunk and 14 seems good enough. Thanks.
>
> -- >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
>
