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

[Thiago Macieira]

On Monday, 24 July 2023 05:34:58 PDT Ivan Solovev via Development wrote:
> > Why doesn't "equals" work?
> > 
> > We've been over this in the code review: our current naming conventions
> > would dictate "equals" even for two arguments, as the most common
> > phrasing is "A equals B" instead of "A and B equal". When you compare
> > things, you always compare at a minimum two of them, so there being two
> > is implied by the act of comparing anyway. And I don't see why we can't
> > provide both static and non- static members, like QString::compare does
> 
> IIUC, the main problem that Marc has in mind is that the existing class
> member equals() would conflict with the two-arg hidden friend equals(),
> which we would use as a helper for operator==() and operator!=().

Then don't use that as the hidden friend. The public API requirements take 
precedence. So long as the problem is not insurmountable, we should make the 
effort to have a clean API because we'll be stuck with it for the next 10 
years.

> The public methods, in turn, are actually an issue, because the compiler
> will
> try to use them instead of a defined hidden friend, even if the number of
> arguments or their types do not match.

And why is that a problem? So long as the proper overload exists, it'll be 
called. There's only a problem if the overloads are ambiguous.

> Probably this approach would allow us to use "equals()" as a name for the E
> function.
> What do you think?

As I said: we should strive for the proper naming.

This also applies to the ordering function be called "compare".

-- 
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/20230724/09591eec/attachment.bin>