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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
