The naming makes sense, given their purpose. But can we put them in a dedicated Qt::std_compat namespace? Or is that too late? That would make it clear these are not Qt proper types (living in the Qt namespace), but dedicated compat types/BC/SC vehicles .
Tor Arne On 14 Nov 2023, at 10:00, Volker Hilsheimer via Development <development@qt-project.org> wrote: On 14 Nov 2023, at 09:40, Marc Mutz via Development <development@qt-project.org> wrote: On 14.11.23 09:31, Marc Mutz via Development wrote: [...] And then naming them Qt::partial_ordering is just consequent, because users can reach ultimate SC by doing something like #ifdef __cpp_lib_three_way_comparison using std::partial_ordering; ~~~~ #else using Qt::partial_ordering; #endif ~~~ use unqualified partial_ordering ~~~ This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by simply saying namespace Qt { using partial_ordering = std::partial_ordering; using weak_ordering = std::weak_ordering; using strong_ordering = std::strong_ordering; } Done. I agree with Marc here. It’s tempting to add some Qt::Ordering::Partial, but it only makes things harder in the not-so-long run. From C++ 23 on, we can expect std::partial/weak/strong_ordering to become as ubiquitous as “true” and “false”. We should not invent our own. Adding Qt::snake_case interims that are BC with std, with conversion from/to QPartialOrdering, is the right thing to do. Volker -- Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development