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

2020-11-05 Thread Jonathan Wakely via Gcc-patches
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

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

2020-11-05 Thread Ville Voutilainen via Gcc-patches
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

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

2020-11-05 Thread Jonathan Wakely via Gcc-patches
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

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

2020-11-05 Thread Jonathan Wakely via Gcc-patches
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 instanti