boost::equality_comparable2 operator== can compile into infinite loop with clang10 and -std=c++2a

[LumaGhost]

#include <boost/operators.hpp>

struct my_type : boost::equality_comparable2<my_type, double> {
    explicit my_type(double mem) : mem_{mem}{}
    double mem_{0};
    operator double() {
        return mem_;
    }
    bool operator==(my_type l) {
        return l.mem_ == mem_;
    }
}; 


int main() {
    my_type x{0};
    return x == double{0};
}

https://godbolt.org/z/zy9L4C

expected: return 1

actual: infinite loop

this minimum example is based on the implementation of BOOST_STRONG_TYPEDEF in the boost serialization library. I originally opened an issue in the serialization library boostorg/serialization#201 although it seems that the problem can be further narrowed down to equality_comparable2

the issue only seems to happen on clang10, clang trunk, and gcc trunk with std=c++2a or std=c++20 flag. clang10 and company produce the expected result when passed the std=c++17 flag instead of 2a. other versions (gcc9 and clang9) produce the expected result even with the std=c++2a flag. I tried with boost 1.72 and 1.73 and they both produce the same behavior. as an additional note, the optimization level does seem to affect the behavior.

let me know if any additional info is required. thank you!

[d-frey]

That's really strange. And it can be reduced even further, up to a point where it doesn't make any sense anymore... https://godbolt.org/z/F5coAY

#include <boost/operators.hpp>

struct my_type : boost::equality_comparable2<my_type, int> {
}; 

int main() {
    my_type x;
    return x == double{0};
}

GIven that C++2a support is AFAIK still experimental, I wonder if this should be a bug report against Clang.

[glenfe]

It's not Clang specific, you'll get the same thing on GCC trunk as well.

[Lastique]

I'm not very familiar with C++20 additions, but it looks like the compiler is now allowed to replace x == y with y == x, in which case the operator== defined here:

utility/include/boost/operators.hpp

Line 161 in 691f323

friend BOOST_OPERATORS_CONSTEXPR bool operator==(const U& y, const T& x) { return x == y; }

becomes infinite recursion. You can see it's a recursion in godbolt with -O0.

[d-frey]

Ah, got it. Yes, it's the space-ship operator causing it, but only because the original example is broken. If you derive from boost::equality_comparable<my_type, double> you must implement an operator== for my_type and double. Relying on implicit conversions doesn't work.

Fixed example: https://godbolt.org/z/15IbkD

[d-frey]

To elaborate: The documentation says that the user must provide t == u, then Boost.Operators will generate u == t, t != u, and u != t.

The problem is that if t == u only works by relying on implicit conversions, the generation of u == t will now cause the new rules that the space-ship operator brought us to prefer the generated operator over the implicit conversions as it thinks it can simply swap the arguments. That creates the infinite loop.

To break it, one needs to provide an implementation for t == u which is a better match and therefore prevents the loop.

[LumaGhost]

If you derive from boost::equality_comparable<my_type, double> you must implement an operator== for my_type and double.

...

To break it, one needs to provide an implementation for t == u which is a better match and therefore prevents the loop.

understood. thank you everyone! 😸

[Lastique]

One thing I'm not getting is that how operator<=> comes into play. I don't see it defined anywhere, and AFAIK the compiler should not implicitly generate one (the user has to opt-in by =default it). And I can't find where the standard allows the x == y -> y == x transform. So I'm not quite sure how the code in #65 (comment) managed to compile.

[d-frey]

The spaceship operator itself <=> is not needed here, but it's addition also brought new rules for ==. It is nicely summarized here: https://brevzin.github.io/c++/2019/07/28/comparisons-cpp20/#summary-of-rules

[d-frey]

Side note: With the new rules, there is pretty much no point in deriving from boost::equality_comparable<T,U> anymore once you implemented the base operator for t==u. The language simply takes care of it :)

[Lastique]

Yes, thank you for the link. So they did add the new rules for the x == y -> y == x transform. But they are described as part of overload resolution ([over.match.oper]/3.4) instead of implicitly generating new operators.

[d-frey]

Yeah, they extend the candidate set for overloads including two special tie-breakers. But in the OPs example all this doesn't help, as the tie-breakers don't eliminate the candidates and the candidates are then a better match than the pre-C++20 overload that was chosen. This is unfortunate and breaks existing programs. Ping @foonathan

[foonathan]

Your assessment is correct. OP wants to compare my_type and double, The only operator== are my_type and my_type (in the class) and double and my_type (from the base class). To use double and my_type the compiler needs to swap args; to use my_type and my_type the compiler needs an implicit conversion to double. As such, the compiler picks the version that swaps. This in turn swaps back, and we have the same problem again.

Yes, this is a breaking change, but the language rules themselves are sensible: you want to prefer the swap over conversion.

There are two solutions here: First, you could argue that the code was always broken as it didn't honor the contract of boost::equality_comparable2 - the implementation of operator==(T, U). Second, you could change your implementation to make the class empty in C++20 - the new rules are sufficient anyway and it just so happens that then the original example works fine and has the same behavior as it did with C++17 (convert to double and compare doubles).

[d-frey]

It was more of an FYI / heads-up. I agree that both the new rules coming with C++20 as well as Boost.Operators are fine, one just needs to provide the correct primary operators. Making the Boost.Operator classes empty for C++20 also seems kind of superfluous, it's better to not derive from them at all - or if you fix the primary operators, it will still work. Thanks for checking, though.