https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116342
--- Comment #5 from Jiang An <de34 at live dot cn> --- (In reply to Zhao Dai from comment #4) > > IIUC GCC and libstdc++ are doing the right thing - you're just not allowed > > to customize comparison for float. > > I don't know if C++ Standard says `strong/weak_order` are customisable only > for user-defined types. If yes, I'm happy to know. This is implied by the uses of ADL, see https://eel.is/c++draft/cmp.alg. As mentioned above, there's no associated namespace for fundamental types, so the behavior of comparison CPOs is fully specified by the standard and can't be customized. > Otherwise, since libstdc++ is customising float comparison with assumptions, > e.g -NaN < -INF < 0 < +INF < +NaN, it sounds like a defect to me if > libstdc++ doesn't allow any other assumptions and use cases. This is the behavior specified in the standard (for std::strong_order). It would be a bit unconfortable for me to describe it as customizing. > Another angle is the original intention of partial/weak/strong_order > customisation points. My understanding is that they "promote" order > categories when needed, like from partial_ordering to weak/strong_ordering > for floating point types. If it's one of the intentions, I don't see why > builtin types and their alias should be excluded. I think the standard intentionally makes operations in the core language and the standard library non-customizable on types that are not program-defined. As a result, implementations can more reliably conclude the validity and equivalency of operations on types fully controlled by the standard and/or the implementations.