[Development] QVariant comparison in Qt6

[Thiago Macieira]

On Saturday, 19 September 2020 11:48:11 PDT Ville Voutilainen wrote:
> Our customers report otherwise. Upgrading Qt and using it on an older
> compiler seems doable
> by a whole lotta customers. Upgrading Qt and upgrading toolchains
> seems much less doable,
> so that would be a bold expectation. Toolchains are "deeper" in
> policy-dictated "infrastructure"
> than you might think.

You clearly have better data than I do and I won't  dispute it. In my world, I 
see both things: system infrastructure is usually fairly established and won't 
change, to the point of people running 3.10 (what comes with RHel/CentOS 7) or 
even 2.6.36 Linux kernels. But the applications themselves and all supporting 
frameworks are actually rapidly and frequently updated, with containers. For 
the past three years, this has been my world: upgrade or get left behind.

> Try convincing a QNX 7 shop that they have to
> use a compiler newer than
> what QNX 7 ships. Try doing the same for some other RTOS toolchains,
> saying that the platform
> and the versions they choose are not sufficient, and they need to
> upgrade to an uncertified
> experimental version, and they'll walk to our competitors asking
> whether they're more reasonable
> about stability and compatibility.

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?). In INTEGRITY's case, since they have to use GHS's compiler, 
there's not even an upgrde possible, even if wanted.

> Same goes for MSVC and GCC if the
> shop is large and non-agile enough,
> and there's no shortage of such shops.

No doubt. But my argument was that:
 a) in my current, professional life, those are getting left behind thus 
    increasingly irrelevant
 b) they don't have to use the new features

If you can't or won't upgrade the toolchain, you can still upgrade Qt. You 
just can't use a few of the the brand, new features.

> 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?

Anyway, I understand your argument and sympathise. I don't have to like it, 
but can commit to it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering