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.
