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

[Thiago Macieira]

On Monday, 31 July 2023 02:36:41 PDT Ivan Solovev via Development wrote:
> > If we are going to expose
> > API, then said API must have proper names and thus must be "equals" and
> > "compare".
> > 
> > But again, these do not need to be the functions that the macros call
> > directly. The macros may call adaptor functions with ugly names.
> 
> What I cannot understand is why we should duplicate the functions? It would
> be much easier if we could use the same functions both for macros and the
> user-specific code.

I'm not saying we have to. I'm saying that we should provide as API for our 
comparable types:
* compare()
* equals()
* operators

Whether the implementation of the latter uses the former two directly is to be 
seen.

> Basically, what you suggest is that for every pair of comparable Qt types
> we would need to double the amount of work that we do - provide not only
> the helper functions for the macros, but also the overload for some
> public functions for the end-users.

Every pair? Under what conditions do we need to implement heterogeneous 
comparisons, outside of the primitives? Even with the primitives, I don't see 
more than a handful of heterogeneous, between integers and floating point, plus 
a few other dispatchers to avoid ambiguous lookups for integer to integer.

It's also not double the amount of work because clearly one set of functions 
would build on top of the other. It's a matter of adaptation in case the non-
ugly names can't be used by the macros.

> Of course, we could try to simplify it. I already started to introduce
> Qt::order() overloads for built-in types in [0].
> So, we could probably provide a general case like this:
> 
>     template <typename L, typename R>
>     auto order(const L &lhs, const R &rhs) noexcept
>     {
>         // or any other uglified name that we choose
>         return qt_order(lhs, rhs);
>     }
> 
> and just let the template fail if qt_order() is not defined for L and R.
> 
> With such approach, we could use qt_equals() and qt_compare() as helper
> functions, and Qt::equals() and Qt::compare() as public API for the users.

Indeed.

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 looking for qLess, but we seem to have dropped 
it with the std::map rewrite for QMap.

> But then, if we use qt_*() functions, their names will not clash with any
> of the existing APIs, and we can just let the end-users use these
> functions directly.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230731/472deb90/attachment.bin>