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

Marc Mutz marc.mutz at qt.io
Tue Nov 14 09:31:30 CET 2023


On 13.11.23 19:24, Thiago Macieira wrote:
[...]
> It could be done, but I just don't see the value.

I do.

> If we do it, please come up with proper Qt-style class names for it. No
> snake_case.

No. We don't _want_ these to be Qt-style classes. _You_ should not want 
them to be Qt-style classes. They're _not_ Qt classes, they're SC and BC 
vehicles to emulate the std classes as close as possible. We don't want 
to have to carry them around come Qt 7. You shouldn't want to have to 
carry them around come Qt 7.

So it must be ::less, not ::Less, and is_neq and not qIsNotEqual. Any 
epsilon of divergence to the std classes will cause users to 
accidentally depend on the difference. Hyrum's Law. So we need to 
minimize that difference as much as humanly possible.

And then naming them Qt::partial_ordering is just consequent, because 
users can reach ultimate SC by doing something like

     #ifdef __cpp_lib_three_way_comparison
     using std::partial_ordering;
     ~~~~
     #else
     using Qt::partial_ordering;
     #endif

     ~~~ use unqualified partial_ordering ~~~

This is the best for our users. Any Qt-ification of these std copies 
will just increase the porting overhead for our users. In no universe 
would that be good for our users. We know where we need to go: no 
Qt::ordering classes, only std::ordering, and anything that distracts 
either our users or ourselves from that goal is counter-productive.

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



More information about the Development mailing list