[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