[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