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

[Ville Voutilainen <ville.voutilainen@gmail.com>]

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.