On 7/14/23 04:31, Jason McKesson via Std-Discussion wrote:
> On Thu, Jul 13, 2023 at 7:49 PM Andrey Semashev via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>>
>> Hi.
>>
>> Recently I got bitten by this innocent piece of code:
>>
>> struct comparible_UDT
>> {
>> int i_;
>> comparible_UDT() : i_(2){}
>> bool operator == (const comparible_UDT& v) { return v.i_ == i_; }
>> };
>>
>> bool test(comparible_UDT left, comparible_UDT right)
>> {
>> return left == right;
>> }
>>
>> This used to work fine until C++20, where the completely broken piece
>> of... core language called operator rewriting appeared. Now gcc and
>> clang mercifully accept this code, albeit with a warning, and MSVC fails
>> to compile it saying the operator== is ambiguous with its rewritten
>> self. Which, of course, I did not write and cannot suppress.
>>
>> https://godbolt.org/z/hsfE8sYfG
>>
>> (Yes, I know I can fix this by marking the operator== as const, that's
>> not the point. The point is that the code above should work as written,
>> there's nothing ambiguous about it.)
>>
>> Could someone explain the rationale behind making this code invalid in
>> C++20? Is there a rationale at all?
>
> Your entire point is premised on the idea that this code was good
> because it worked. That the code was "innocent".
>
> But it wasn't. It was something you could get away with, but it was
> ultimately not good code. Besides the fact that you could technically
> call the function, what is the rationale that says that this code was
> *sensible* even when it worked?
>
> Unless you are doing something special with `operator==`, there is no
> reason for it not to be `const`. In fact, your function even takes a
> proper `const&` of the other item. But how does that make sense? How
> can a symmetric `==` be a `const` operation on one of its items but
> not on the other?
>
> What does it mean that `this` is not `const`?
>
> If you made it a proper `const` function, not only would the error go
> away, you would have *better code*. Code that more accurately
> describes what it is doing.
>
> While there are some cases of legitimately reasonable code that
> operator rewriting broke, this is not one of them. This is a trivially
> fixable problem where the original code was already dubious even if
> the compiler was silent about it.

So are you saying non-const-qualified operator== is banned now? Seriously?

I'm sorry, but with all due respect, you're not the one to decide
whether the code is "good" or "bad". Nor is anyone in the committee. The
code may need to discriminate const and non-const objects, or it may
need to count operator== calls, or there may be any other reason for it
to be not const-qualified. You don't know that, and the standard
doesn't. It's not the standard's business to tell people what is "good"
or "bad". It is to tell what is "valid" or "invalid". And I don't see
the reason for this code to be invalid.