I feel we're turning in circles here, so let me give a rundown of what I thought we might meet at:
- Introduce Qt::{partial,weak,strong}_ordering - BC and SC-as-much-as-possible to std::*_ordering - Qt 7: Qt::foo_ordering becomes a typedef for std::foo_ordering, like QPair in Qt 6 - QPartialOrdering stays as-is - except it gets implicit conversions to Qt::_ordering types - (undecided) ditto _to_ Qt::_ordering types This means QVariant and QMetaType keep using QPartialOrdering, but that's ok, they're anyway type-erased, so some overhead is expected. QVariant, in particular, only has a static compare() function that returns QPartialOrdering. An eventual compareThreeWay() would return Qt::partial_ordering. All other std::regular Qt classes will be using the new types (or, if helper functions are inline and we compile in C++20 mode, the std types directly). On 14.11.23 18:20, Thiago Macieira wrote: > On Tuesday, 14 November 2023 08:25:34 PST Ivan Solovev via Development wrote: >>> The ABI functions can return one of these other types: >>> bool (for equality comparisons) >>> int (for non-partial ordering) >>> QPartialOrdering (for partial ordering) >> >> IIUC, returning QPartialOrdering is exactly what we want to avoid, due to >> the std::partial_ordering -> QPartialOrdering (and reverse) conversions. > > That boat sailed in 6.1 because QPartialOrdering is already used in QMetaType > and QVariant API/ABI. As per the above, these classes can continue to use QPO. QVariant, in particular, when ported to the new macros, will use Qt::partial_ordering in compareThreeWay() and QPO in compare(). Shit happens. > Ideally for new out-of-line APIs, we could return a type that is ABI- > compatible with std::partial_order. That are the Qt::_ordering types, yes. > But how many of those are we going to get? Every ordered Qt class. I didn't count, but sufficiently many to matter. >> As we figured out earlier in this discussion, by making Qt::partial_ordering >> binary compatible with std::partial_ordering, we will allow the compiler to >> optimize the code and avoid the conversions (specially if we use >> std::bit_cast). > > Yes, but the impact only applies to when it needs to translate from out-of- > line to out-of-line. If either side is inline, it'll do the right thing on its > own. Yes. If either side is inline, you still get the conversion operators emitted in debug mode, which Qt tends to optimize for, too. That's one of the reasons why, even with {std,Qt}::_ordering types being BC to each other, it makes sense to return std in C++20 builds and Qt in C++17 builds. Thanks, Marc -- Marc Mutz <marc.m...@qt.io> Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development