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

[Marc Mutz]

On 19.09.23 15:09, Volker Hilsheimer wrote:
[...]
> What Thiago wrote makes sense to me:
> 
>> On 31 Jul 2023, at 17:23, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
>> 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.
> 
> 
> Separating the implementation from the public API seems to me the only way to end up with a clean public API, while at the same time have a macro-friendly convention. The implementation can live in a private function with a name not suitable for a public API, e.g. “qt_equals/qt_compare”; those can be used by the macro declaring the operators.
> 
> Types for which we then want public APIs as well (and I agree that it’s strongly preferable to have this for all relevant types in the long run) can declare public equals()/compare() functions that ideally use the private functions.

We already have QString::compare() as an example how to _not_ do this 
kind of API: it's an absolute catastrophe: What is a user to use? 
QString::compare()? QStringView::compare()? 
QLatin1StringView::compare()? Each one works for a certain set of 
argument types, none works for all. And that's even "concrete" code. If 
we're taking generic code into account, it gets totally unworkable: It 
makes helper functions a la qHashMulti() impossible to write.

Remember that the overarching goal is to make the implementation and 
documentation of the relational operators for Qt types _easy_. That 
means we provide the macros for defining the public interface, and 
documentation, but we also need to provide such implementation helpers 
as qHashMulti() to help implement the required two functions. That, in 
turn, requires a _uniform_ interface to the functionality. Besides, if 
we require every class author to maintain a separate, public API on top 
of what the macros need and provide, we lose simplicity. And since it's 
now up to the class author to pick a name and document the function, we 
also lose consistency.

> I do not see the need for adding more qOperator type global functions.

You lost me here, but I assume that you're talking about what I call 
(4). There must be _one_ global template. It calls (2) or (3) via (1). 
Everything else is a novel idea that must argue against 30 years of C++ 
and 30 years of Qt experience. qFoo would be that (4). A class-static 
cannot be that (4).

Taking a step back:

 From my POV, we had good names lined up for 6.6: Qt::order/ing, 
Qt::equal, qOrder, qEqual, etc. They were chosen _because_ they meet all 
requirements and they model what we and C++ already have for swap(). 
They don't pessimise KDE types vs. Qt types. Whatever we choose will 
become consistent simply by being available for virtually all Qt types, 
eventually. I expect all bike-shedding to meet the constraints laid out. 
Demanding the impossible is not helpful.

We need this framework to check our operators for symmetry before we can 
claim C++20 compatibility (we're already getting BRs about 5.15 not 
compiling with C++20), and this discussion is holding up that work, 
which was planned for 6.6 and now we're close to missing 6.7, too.

We _know_ equal/eq/order/ordering/cmp _work_. Ivan and I did the work. 
If anyone thinks they can come up with better names, don't just throw 
your hat into the ring. Code it for out for a few classes. Incl. 
QString, of course.

So I ask: Please let us roll out the framework with one of 
equal/eq/order/ordering/cmp (your choice, but quickly!), to set a status 
quo against which to benchmark any potentially-superior solutions, and 
then the ML can finish bikesheddding and if the discussion yields 
something better, I think I speak for Ivan, too, when I say that we're 
committed to porting to that.

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