[PATCH] Fix const constraint in std::stable_sort and std::inplace_merge

[François Dumont]

On 02/10/2024 19:07, Jonathan Wakely wrote:
> On Wed, 2 Oct 2024 at 17:39, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On Wed, 25 Sept 2024 at 18:22, François Dumont <frs.dumont@gmail.com> wrote:
>>> Hi
>>>
>>> Once https://gcc.gnu.org/pipermail/libstdc++/2024-September/059568.html
>>> will be accepted we will be able fix this long lasting issue that
>>> std::stable_sort and std::inplace_merge are forcing the functor to take
>>> const& parameters even when iterators used in range are not const ones.
>> https://cplusplus.github.io/LWG/issue3031 said that's OK.

At least not "fixing" this in pre-C++11 mode is not a problem then.

And AFAIU the resolution it does not say that allowing it is forbidden 
neither.

Should I add the test case shown in the Issue to the testsuite ? It's 
still UB no ?


> And ... I guess that means we don't need to worry about the non-const
> X::operator<(X&) case?
>
> Before C++20 the standard implied it should work, and that's what
> we've traditionally supported. But maybe we can stop supporting that,
> if we treat the C++20 change as a DR for previous standards?
>
> Hmm. That would make your clean-up a lot simpler. That's what you had
> in the earlier patch, right?
>
I cannot remember and could check but to be honest I'm quite proud of 
the proposal. I find it already much simpler that the current approach.

I don't think Issue 3031 resolution is proposing to force const-ness but 
if needed it would be very easy to do so with my proposal.

Note that I recently run all testsuite with both patches under Linux x64 
using default -std and got no regression. I'll run it one more time for 
C++98 though.