[Development] QVariant comparison in Qt6

Ville Voutilainen ville.voutilainen at gmail.com
Mon Sep 21 19:30:58 CEST 2020


On Sun, 20 Sep 2020 at 09:02, Thiago Macieira <thiago.macieira at intel.com> wrote:
> Hmm... I had clearly forgotten about QNX and INTEGRITY, especially the latter.
> I thought the problem with QNX was solved since they switched to Clang (or
> haven't  they?).

QNX 7 AFAIK has a compiler based on GCC 8. Switching to Clang doesn't
solve this problem; the
problem is that such a platform sticks with a particular compiler
(major) version for the lifetime of
the platform, and during that time, there's now three new C++ standards out.

> > Providing optional support for C++20 facilities like spaceship etc. is
> > fine. Making significant functionality
> > available for C++20 users only, when we don't have to, is not so fine.
> > Especially since it's not portable,
> > and leads to a splintered Qt, as opposed to a portable Qt.
>
> How about non-significant functionality? For example, you get operator== and a
> compare() function, but if you want the other actual operators, get the
> spaceship?

Well, that depends on whether the ordering is really insignificant. If
it's significant, then we
should provide the relational operators even if we can't spaceship
them for everybody.
If it's just additional icing on the cake and we manage to convince me
that the feature is
infeasible to maintain unless written in terms of spaceship.. ..maybe.
Somehow this
smells like "if I can't have my toy with the newest adornments from
the shop, I don't want
it at all". :) What <compare> does is that it provides a wholesale
model for comparisons
and ties language and library facilities together in a (arguably
well-)knit framework, but
it doesn't overnight make user-provided comparisons written in the
traditional way invalid.
Especially if those comparisons are "sane" as expected by the
spaceship rules (which are over-draconian,
anyway).


More information about the Development mailing list