[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Tor Arne Vestbø
Tor.arne.Vestbo at qt.io
Tue Nov 14 12:01:12 CET 2023
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 at qt-project.org> wrote:
On 14 Nov 2023, at 09:40, Marc Mutz via Development <development at 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 at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231114/18d4f15a/attachment.htm>
More information about the Development
mailing list