Final C++20 rules and -Wambiguous-reversed-operator

Hi,

It looks like the working of C++20 introduced some breaking compatibilities with some C++17 accepted patterns. From what I read in https://reviews.llvm.org/rL375306 these incompatibilities weren’t really intented by the initial C++20 proposal, and thus broken patterns were still allowed as an extension, but would warn with -Wambiguous-reversed-operator enabled by default. Richard Smith had some hope that the C++20 standard would be fixed before being final.

C++20 is not fully finalized yet, but this date is approaching. What’s the state of the standard now ? Have the comparison issues been fixed ? If not, what do you suggest to users ? Fix the code (when it’s actually possible and make sense), or compile with -Wno-ambiguous-reversed-operator ? I am asking this question in the particular case of boost date_time: https://github.com/boostorg/date_time/issues/132 where I am actually unsure this is a good idea to change the existing code.

Cheers,
Romain

Hi,

It looks like the working of C++20 introduced some breaking compatibilities with some C++17 accepted patterns. From what I read in https://reviews.llvm.org/rL375306 these incompatibilities weren’t really intented by the initial C++20 proposal, and thus broken patterns were still allowed as an extension, but would warn with -Wambiguous-reversed-operator enabled by default. Richard Smith had some hope that the C++20 standard would be fixed before being final.

C++20 is not fully finalized yet, but this date is approaching. What’s the state of the standard now ? Have the comparison issues been fixed ?

No, we still don’t have a resolution from the C++ committee, but it’s being discussed by various implementers, and we hope to present to the committee a suggested set of changes to minimize the pain to users as soon as we can. I expect we will change /something/ as a DR fix against C++20, but the exact details are unclear.

If not, what do you suggest to users ? Fix the code (when it’s actually possible and make sense), or compile with -Wno-ambiguous-reversed-operator ? I am asking this question in the particular case of boost date_time: https://github.com/boostorg/date_time/issues/132 where I am actually unsure this is a good idea to change the existing code.

If you can change the code in a way that’s compatible with the C++20 rules, that will give you the best portability across compilers in the short term. If Boost is prepared to wait until this is fixed before supporting -std=c++20, then that would seem reasonable too.

Hi,

Thanks for the heads up.

I am not sure how valid is my request, but I found a case where I wished -Wambiguous-reversed-operator would avoid what today with clang 10 is a strong error.

Consider this code: the == comparison warning is avoidable with -Wambiguous-reversed-operator, but not the != comparison. This make existing C++17 code behavior non-symetric when migrating to pack C++20, and a bit awkward for users:

template <typename T> struct A
{
    bool operator==(const T&) const;
    bool operator!=(const T&) const;
};

struct B : public A<B> {};

bool f()
{
    bool a1 = B() == B(); // Works, only a -Wambiguous-reversed-operator warning
    bool a2 = B() != B(); // Strong error, which you can't avoid with -Wno-ambiguous-reversed-operator flag
}

Do you think that in the meantime while we wait for the C++ committee to standardize a real DR clang 10 should be update to also just warns in such cases involving != ?

Cheers,
Romain

At this point it’s likely too late to do anything different for Clang 10… but the rule we’re discussing to fix this issue would make the above case work. I’ll see about implementing that sooner rather than later.