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

[Ivan Solovev]

I'm now re-reading the discussion, and I think that I missed one thing
previously, so let me comment on that.

> What I meant is that the product API of using the macros are the set of
> operators. The methods that those operators called are not API and users are
> not expected to use them in their code. In fact, if conflicting names are a
> problem, then we should uglify the names we're asking for in the macros by
> inserting a "q_" or "qt_" prefix.
>
> This means C++17 users are able to use all operators to produce a boolean
> result, but can't get a QXxxOrdering result with homogeneous API from the
> macros.

The new macros are supposed to be publicly available. This means that the
users will be able to use them in their custom classes to implement the
unified comparison behavior between C++17 and C++20.

This means that the users will need to provide their implementations of
the helper methods. The idea is to explicitly mention it in the docs,
so the methods cannot be considered "Qt internal" anymore.
Can we use the "q_" or "qt_" prefix for these helper functions in this case?

Or do you suggest making the macros Qt-private? Not that we *really* can
do it, because the macros are exposed in public headers, but we can at least
hide the documentation, and do not advertise the macros...
But IMO such decision would significantly decrease the value of the new
feature.

> We still need *some* level of public API to produce ordering results because
> users will need those methods to produce their own comparison functions, such
> as composing on top of our string or date/time classes. If they want to also
> be compatible with C++17, then they can't use the spaceship, and instead they
> will need to call a named function of some sorts. If we are going to expose
> API, then said API must have proper names and thus must be "equals" and
> "compare".

The initial idea was that the helper functions could also become the public
API for producing ordering results. IIUC, that's also why Marc suggested to
make them hidden friends. Using private 2-arg static function would work for
the comparison operators but wouldn't work as a public API. Hidden friends
will work for both cases.

If we advertise only the public API which is not supported by the macros,
then the users will still need to implement all six (or 12 in case of
mixed-type comparison) relational operators instead of just calling one macro
and implementing two helper functions.

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

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: Development <development-bounces at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Tuesday, August 1, 2023 5:11 PM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Tuesday, 1 August 2023 01:55:05 PDT Ivan Solovev via Development wrote:
> > BTW, this needs to integrate with QEqualityOperatorForType and
> > QLessThanOperatorForType in qmetatype.h. I don't think there's any work
> > for
> > you other than verifying.
>
> I was not even aware of them, thanks! A brief look at the code shows that
> they shouldn't be affected, but I'll update the Jira ticket to keep them
> in mind.

I wasn't either. I went looking for qLess, which existed for Qt 3, 4 and 5 for
Q(Value)Map, and found them.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230814/143b1967/attachment.htm>