[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

Volker Hilsheimer volker.hilsheimer at qt.io
Tue Nov 14 13:11:49 CET 2023


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.

On 14 Nov 2023, at 11:54, Edward Welbourne <edward.welbourne at qt.io> wrote:
Adding Qt::snake_case interims that are BC with std, with conversion
from/to QPartialOrdering, is the right thing to do.

Perhaps namespace q20 would be a better place for them, given both the
naming (snake-case, to match stl) and the plan ?

and

On 14 Nov 2023, at 12:01, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:

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


We have so far not used any q20/23/xp APIs in public Qt API, and those namespaces are not documented. The intention was for them to be used internally, and the qNN headers contain the “not part of the Qt API” warning. This doesn’t have to be set in stone, of course. Perhaps this is the exception that confirms the rule.

OTOH, if the only reason for not using Qt::snake_case is because of the snake_case, then it seems overly complicated to make that exception, or to introduce a new namespace. It’s going to be part of practically every value-type we have in Qt, which makes it a very very ubiquitous “exception”. We have QList::push_back and QList::const_iterator for compatibility with the standard. I don’t quite see why it would not be ok for Qt::*_ordering to exist as a proper Qt names. The only difference here is that we don’t want to introduce a Qt::CameCase equivalent, for the reasons given by Marc.

That they are short-lived as “independently defined entities” is an implementation detail. Qt::*_ordering will work throughout the Qt 6 life-time, also once they are just aliases to std::*_ordering; there won’t even be a real reason to remove them for Qt 7.


On 14 Nov 2023, at 11:54, Edward Welbourne <edward.welbourne at qt.io> also wrote:
Speaking of q20, I notice its files live in corelib/global/; it occurs
to me that perhaps corelib/compat/ might be more natural (mainly because
it's the first place I looked for them).  They are, after all, a piece
of compatibility machinery, albeit between Qt and C++ rather than
between Qt versions (as such - of course, the Qt versions' change of C++
standard does make them indirectly also between Qt versions).

Eddy.

module/compat is about backward compatibility with older Qt versions, and in practice only includes the respective removed_api.cpp implementation file.

We include those qNN headers in public headers, and including something from “compat” in public headers seems wrong.

Volker


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231114/45f79346/attachment-0001.htm>


More information about the Development mailing list