[committed] libstdc++: Fix constraints on std::optional comparisons [PR 96269]

[Jonathan Wakely]

On 05/11/20 22:12 +0200, Ville Voutilainen via Libstdc++ wrote:
>On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
><libstdc++@gcc.gnu.org> wrote:
>>
>> On 05/11/20 19:09 +0000, Jonathan Wakely wrote:
>> >The relational operators for std::optional were using the wrong types
>> >in the declval expressions used to constrain them. Instead of using
>> >const lvalues they were using non-const rvalues, which meant that a type
>> >might satisfy the constraints but then give an error when the function
>> >body was instantiated.
>> >
>> >libstdc++-v3/ChangeLog:
>> >
>> >       PR libstdc++/96269
>> >       * include/std/optional (operator==, operator!=, operator<)
>> >       (operator>, operator<=, operator>=): Fix types used in
>> >       SFINAE constraints.
>> >       * testsuite/20_util/optional/relops/96269.cc: New test.
>> >
>> >Tested powerpc64le-linux. Committed to trunk.
>>
>> When concepts are supported we can make the alias templates
>> __optional_eq_t et al use a requires-expression instead of SFINAE.
>> This is potentially faster to compile, given expected improvements
>> to C++20 compilers.
>>
>> I'm testing this patch.
>
>It concerns me that we'd have such conditional conceptifying just
>because it's possibly faster to compile.
>There's more types where we'd want to conditionally use concepts, but
>perhaps we want to think a bit
>more how to do that in our source code, rather than just make them
>preprocessor-conditionals in the same
>header. We might entertain conceptifying tuple, when concepts are
>available. That may end up being
>fairly verbose if it's done with preprocessor in <tuple>.
>
>That's not to say that I'm objecting to this as such; I merely think
>we want to be a bit careful with
>conceptifying, and be rather instantly prepared to entertain doing it
>with a slightly different source code
>structure, which may involve splitting things across more files, which
>would then involve adding more
>headers that are installed.

I agree. I only considered doing it here (and am posting it for
comment rather than committing it right away) because we already have
the alias helpers which are used in multiple places in the file.
Without those, every relational operator would look like this if we
used concepts conditionally:

   template<typename _Tp, typename _Up>
     constexpr auto
     operator==(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
#if __cpp_lib_concepts
     requires requires(const _Tp __t, const _Up __u) {
       { *__lhs == *__rhs } -> convertible_to<bool>;
     }
#else
     -> enable_if_t<is_convertible_v<
         decltype(std::declval<const _Tp&>() == std::declval<const _Up&>()), bool>,
         bool>
#endif
     {
       return static_cast<bool>(__lhs) == static_cast<bool>(__rhs)
	     && (!__lhs || *__lhs == *__rhs);
     }

Or:

   template<typename _Tp, typename _Up>
     constexpr auto
     operator==(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
#if __cpp_lib_concepts
     requires requires { *__lhs == *__rhs } -> convertible_to<bool>; }
#else
     -> enable_if_t<is_convertible_v<decltype(*__lhs == *__rhs), bool>, bool>
#endif
     {
       return static_cast<bool>(__lhs) == static_cast<bool>(__rhs)
	     && (!__lhs || *__lhs == *__rhs);
     }

Yuck.

The second one is less verbose, but does overload resolution and type
deduction for optional<_Tp>::operator* and optional<_Up>::operator*.
That's unnecessary (and so compiles slower) because we know the result
types are just const _Tp& and const _Up&, so the first version uses
those types directly.

Either way, having that #if-#else-#endif on every relational operator
is NOT appealing. But since all the operators already use aliases like
__optional_eq_t any changes are localized to those helpers. The actual
rel ops themselves don't change.

We definitely want to think about the trade offs though. So far we
only use concepts in code that only has to compile as C++20, so we
don't need to provide a non-concepts fallback for C++17, or where it's
required for conformance (e.g. iterator_traits). That's definitely
more palatable than preprocessor conditions choosing between two
functionally equivalent ways to do the same thing.