On Sat, 19 Sep 2020 at 06:28, Thiago Macieira <[email protected]> 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. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
