On 05/11/20 22:12 +0200, Ville Voutilainen via Libstdc++ wrote:
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
<libstd...@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.
