Re: [committed] libstdc++: Fix constraints on std::optional comparisons [PR 96269]
On 05/11/20 22:12 +0200, Ville Voutilainen via Libstdc++ wrote:
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
wrote:
On 05/11/20 19:09 +, 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 .
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
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;
}
#else
-> enable_if_t() == std::declval()),
bool>,
bool>
#endif
{
return static_cast(__lhs) == static_cast(__rhs)
&& (!__lhs || *__lhs == *__rhs);
}
Or:
template
constexpr auto
operator==(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
#if __cpp_lib_concepts
requires requires { *__lhs == *__rhs } -> convertible_to; }
#else
-> enable_if_t, bool>
#endif
{
return static_cast(__lhs) == static_cast(__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.
Re: [committed] libstdc++: Fix constraints on std::optional comparisons [PR 96269]
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++ wrote: > > On 05/11/20 19:09 +, 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 . 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.
Re: [committed] libstdc++: Fix constraints on std::optional comparisons [PR 96269]
On 05/11/20 19:09 +, 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.
commit c5d8e2ba0ad20425cc7778152824d9e5267b0ec5
Author: Jonathan Wakely
Date: Thu Nov 5 19:45:52 2020
libstdc++: Use concepts to constrain std::optional relops
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.
libstdc++-v3/ChangeLog:
* include/std/optional [__cpp_concepts] (__optional_eq_t)
(__optional_ne_t, __optional_lt_t, __optional_gt_t)
(__optional_le_t, __optional_ge_t): Use requires-clause on
alias template.
diff --git a/libstdc++-v3/include/std/optional b/libstdc++-v3/include/std/optional
index 5ea5b39d0e69..4e9618648250 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -998,9 +998,48 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
void reset() noexcept { this->_M_reset(); }
};
+#if __cpp_lib_concepts
+ template
+requires requires (const _Tp __t, const _Up __u) {
+ { __t == __u } -> convertible_to;
+}
+using __optional_eq_t = bool;
+
+ template
+requires requires (const _Tp __t, const _Up __u) {
+ { __t != __u } -> convertible_to;
+}
+using __optional_ne_t = bool;
+
+ template
+requires requires (const _Tp __t, const _Up __u) {
+ { __t < __u } -> convertible_to;
+}
+using __optional_lt_t = bool;
+
+ template
+requires requires (const _Tp __t, const _Up __u) {
+ { __t > __u } -> convertible_to;
+}
+using __optional_gt_t = bool;
+
+ template
+requires requires (const _Tp __t, const _Up __u) {
+ { __t <= __u } -> convertible_to;
+}
+using __optional_le_t = bool;
+
+ template
+requires requires (const _Tp __t, const _Up __u) {
+ { __t >= __u } -> convertible_to;
+}
+using __optional_ge_t = bool;
+
+#else // concepts
+
template
using __optional_relop_t =
- enable_if_t::value, bool>;
+ enable_if_t, bool>;
template
using __optional_eq_t = __optional_relop_t<
@@ -1031,6 +1070,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using __optional_ge_t = __optional_relop_t<
decltype(std::declval() >= std::declval())
>;
+#endif // concepts
// Comparisons between optional values.
template
