<optional>: Potential constraint recursion for operator<=>(const optional<T>&, const U&)

[CaseyCarter]

While implementing <=> support for std::optional we stumbled across what appears to be constraint recursion for the operator<=> signature specified in [optional.comp.with.t]/25 when the second argument is a specialization of optional. Specifically, checking three_way_comparable_with seems to recurse via checking the constraint that e.g. < is viable for operator<(const optional<T>&, const optional<U>&), which it certainly is if <=> is provided by the first signature. We avoided the recursion by adding an additional constraint to the first signature requiring that U is not a specialization of optional, which is checked before the three_way_comparable_with constraint.

STL/stl/inc/optional

Lines 646 to 650 in 4c862ee

	template <class _Ty1, class _Ty2>
	requires (!_Is_specialization_v<_Ty2, optional>) // TRANSITION, GH-1674
	&& three_way_comparable_with<_Ty1, _Ty2>
	_NODISCARD constexpr compare_three_way_result_t<_Ty1, _Ty2>
	operator<=>(const optional<_Ty1>& _Left, const _Ty2& _Right) {

Looking at it now (with the workaround disabled) the recursion only manifests when compiling with Clang. Given how differently Clang and MSVC handle C++20 relational operator rewrites it's not clear to me if the constraint recursion is real or an artifact of said rewrites in Clang. We need to reduce this to something library-free and then determine whether the bug is in Clang or the C++ Standard and deal with it appropriately. (I will nonetheless tag this "LWG issue needed" for the time being.)

[jwakely]

I think this is a defect in the standard library. Libstdc++ is missing the three_way_comparable_with<U,T> constraint on operator<=>(const optional<T>&, const U&) but once I add it, GCC also hits this constraint recursion (and an ICE).

[CaseyCarter]

I've submitted an LWG issue for this defect - with our workaround as proposed resolution - and will report back here when LWGChair assigns an issue number. We can then change the // TRANSITION, GH-1674 comment to // LWG-XXXX and close this issue.

[CaseyCarter]

This is LWG-3566; #2011 updates the comment in <optional> to refer to the LWG issue and closes this issue.