On Friday, 22 September 2023 05:46:27 PDT Marc Mutz via Development wrote: > Where do you draw the line between "Allowing class developers to > implement the three-way comparison such that Qt can make use of it is > fine." and "Providing an API for three-way comparison in C++17 does not > need to happen."?
At our maintenance cost. If it costs us more to create something they can use,
then it needs to be long-term justified. A short-term requirement for people
who can't upgrade requires a very high justification.
> How is said Qt class author supposed to implement his cmp(lhs, rhs) if
> there is no "API" for doing this on his data members? As a concrete
> example, how is the author of a `struct QFoo { int; QString; }` supposed
> to implement his cmp() if all he gets is op<=>, a C++20-only API?
How they implement their three-way comparison for their internals is their
problem. So long as they somehow provide the method that our macros require,
they can use the macros.
But we don't have to help them there. We can't help them with types from
third-party libraries we don't know about in the first place; they have to
implement the three-way comparison themselves anyway. Having a (4) that allows
them to compare Qt types and compose solves 99% of the problems. For the rest,
they can figure out on their own or just use the spaceship operator.
And this is even assuming that we document the macros for public use in the
first place.
> I don't see how we can manage without an API for doing three-way
> comparisons in C++17.
>
> We can try without (4), but (1)-(3) must needs be "semi-public" API (not
> in _p.h's).
I'm ok with semi-public. That means I can change them or remove them.
--
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
