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

[Marc Mutz]

TL;DR: "a" must not be a name of an existing function in Qt.

On 18.09.23 10:15, Ivan Solovev via Development wrote:
> Hi,
> 
>  > 1. an ADL-able calling convention:   `using std::swap; swap(lhs, rhs);`
>  > 2. an implementation for built-in types: `std::swap`
>  > 3. an implementation for user-defined types: ADL `swap`
>  > 4. (optionally) a convenience wrapper: `std::ranges::swap()`, `qSwap`
> 
> One more question here - do we want our users to be able to do (1), or
> is it enough to expose only (4) to them?
> The reason for my question is (again) naming, see below.

I see no reason to withhold the like of KDE an API to adapt their types 
to C++20 semantics while at the same time maintaining compatibility with 
C++17. But if we can't agree on naming otherwise, then I guess we'll 
have to make it private and KDE will use it anyway, and everyone will 
wish we had made it public.

>  > My original proposal had, for equality, a = equal, b = Qt, c = qEquals,
>  > and for ordered types, a = order, b = Qt and c = qOrder (or qCompare,
>  > don't remember which).
> 
> I was about to suggest a = `qt_equals`, b = `Qt`, c = `qEquals`, but that
> would result in ugly `Qt::qt_equals()` calls.
> 
> But if we say that the users should only use `qEquals()` and `qCompare` in
> their code, then we can use ||`QtPrivate` as the namespace​:
> a = `qt_equals`,    b = `QtPrivate`, c = `qEquals`     for equality, and
> a = `qt_compare`, b = `QtPrivate`, c = `qCompare` for ordering.
> 
> AFAIK, the most critical drawback of qSwap() was the compilation speed
> when having it in every value class, so I would not expect Qt itself to use
> `qEquals` and `qCompare` everywhere.
> But would it be ok for the user code?
> 
> What do you think?

I think that users like KDE that have large Qt-based class libraries and 
traditionally use our class implementation macros no matter what we say, 
will want to be treated like a Qt module, so requiring them to only use 
(4) while we ban the use of (4) in most Qt code, is not going to amuse 
them.

> Other idea that came to my mind while writing this - just do not provide 
> (4),

That is also an option.

> since it has known issues (at least with compilation speed). Then we can
> use
> a = `qEquals`,     b = `Qt` for equality, and
> a = `qCompare`, b = `Qt` for ordering.
> We already have `QTest::qCompare()`, so `Qt::qCompare` would not be
> a much worse naming.

I don't really want to think about the implications of an ADL-enabled 
qCompare() on code in the QTest namespace... I don't think we should 
afford ourselves the inconveniences of unintended overloading.

Remember the problem with equals() and compare(): we have classes with 
these functions, and, regardless of whether they're static or 
non-static, binary non-member or unary member functions; name lookup 
will _stop_ at class scope when it finds the name, and it will _not_ 
continue to look in outer scopes just because the arity or argument 
types don't match. You will just get a compile error (if lucky) or 
something unexpected called (if not). Yet, that is exactly what we need 
for the case where func(A, B) is resolved in terms of func(A, A(B)) 
(implicit conversions).

qCompare() may have the same problem.

> Anyway, it would be great to come to some kind of consensus about the
> naming of the APIs, and move on to the actual implementation.

+1

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

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

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B