[Development] QVariant comparison in Qt6

[Ville Voutilainen]

On Sat, 19 Sep 2020 at 06:28, Thiago Macieira <thiago.macieira at intel.com> wrote:
> But for other things, I'm not shy about it. People can't complain that they
> can't use features that didn't exist when they wrote their application.  If
> they want to use new features, it stands to reason they've just upgraded Qt.
> If they can do that, they should be able to upgrade their compiler and
> toolchain too.

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

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.