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

[Ivan Solovev]

Hi,

I'd like to discuss one more topic regarding the C++20 comparison.

Can we allow an `auto` return type in helper functions and the three-way
comparison implementation for the built-in types?

The idea is that these methods can return `Q*Ordering` types in C++17 mode, and
`std::*_ordering` types in C++20 mode.

The question was raised and discussed here:
https://codereview.qt-project.org/c/qt/qtbase/+/478199/comment/bbab752c_520dc684/

Now we have two controversial opinions.

The main reason to use `auto` is that it will allow us to avoid unnecessary
`std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20
case, which will hopefully be the common case going forward.

The main argument agains it is the possible ODR violation when mixing C++17
and C++20 in one binary.

So, my question is - shoud we support mixing C++17 and C++20 in one binary?

Before continuing with the patches, I'd like to hear more opinions.

Thanks,
Ivan

________________________________
From: Ivan Solovev <ivan.solovev at qt.io>
Sent: Wednesday, October 4, 2023 11:15 AM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

So, let me give another update.

The chaing ending in https://codereview.qt-project.org/c/qt/qtbase/+/508464
passed a full pre-check in the CI.
It implements the macros in terms of helper functions ``comparesEqual()``
and ``compareThreeWay()``.
The macros are documented as internal for now.

It also provides ``qCompareThreeWay()`` as a public API for three-way
comparison.

The chain also contains examples of applying the new macros to some of the Qt
classes: QTime, QDate, QDateTime, QTimeZone, and qfloat16.

I think, Marc also started migrating more Qt classes to the new macros.

We also have a draft of a QUIP which describes how to apply the new macros
to the Qt classes: https://codereview.qt-project.org/c/meta/quips/+/490932

------------------------------

Ivan Solovev
Senior Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solovev at qt.io
www.qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
________________________________
From: Edward Welbourne <edward.welbourne at qt.io>
Sent: Tuesday, September 26, 2023 4:31 PM
To: development at qt-project.org <development at qt-project.org>; Ivan Solovev <ivan.solovev at qt.io>
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

Thiago wrote:
>> See my other email: the (1) is not discoverable, teachable, or
>> particularly understandable by average C++ developers. It is not a
>> good corner of C++.

Ivan Solovev (21 September 2023 11:10) replied:
> As you correctly pointed out, most of the developers will just use
> public operator==(), and, come C++20, operator<=>().
>
> But I'd say that if someone wants to implement three-way comparison
> for their classes in C++17, then a bit better understanding of the
> language features is a reasonable expectation.

You're not thinking of all the different users of code.  The author of a
class using Qt, that opts to use our mechanism for comparisons, can
indeed be expected to understand the fancy new language features, around
which that mechanism is built.

However, the client of that code, who just wants to compare two things,
is a separate player in the game; you're also expecting them to have
that level of sophistication.  That's more of a stretch: they're just
trying to coax their template into coping with one of its parameters
being this class that someone using Qt has exposed to them in a library
they're using.  They may not even be using Qt themselves, merely
publishing a helper template that someone else is trying to use in
conjunction with some classes written using Qt.  We don't want them to
throw up their hands and tell the users of their template they don't
support use of Qt classes with their templates because "Qt does things
weirdly" (as far as they're concerned).

        Eddy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231107/034c6093/attachment.htm>