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
