Hi Thiago, While I'd rather sooner than later see us switch to C++20, ever since 5.7, we have dropped supported compilers only after an LTS release (5.6, in that case).
Since I agree the train for 6.6 has left the station, as Integrity (and possibly QNX?) don't have an official C++20 offering, yet (https://ghs.com/products/compiler.html, IIRC, they're going to release one this year, but I don't know what features they're shooting for), I was assuming that 6.9 would be the next option. Personally, I would support a break after 6.8. That's scheduled for release in summer/autumn 2024, and has three years LTS, so gives affected customers until autumn 2027 to update their tool-chains. By that time, C++26 will be out already. Even that, within TQtC, is seen as too early by some. After all, we still support 5.15 and therefore C++11, in 2023. That's only because 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a VLTS release, too, if sufficient numbers of customer won't be able to upgrade to C++20 by 2027. From a maintenance POV, it should be easier to support a C++17-based VLTS release than one that's still stuck on C++11 (and doesn't actually test for compatibility with that version in the CI...). Thanks, Marc On 03.05.23 02:39, Thiago Macieira wrote: > C++23 is on the way, so maybe it's time for us to raise our minimum to the one > version before that. Let's aim for Qt 6.7, because feature-freeze for 6.6 is > within one month, and lets us warn our users this is coming. > > By this, I mean to: > * modify our build system so Qt compiles with -std=c++20 or equivalent > * require that user code compiling Qt headers be similarly done > * remove the requirement for #if checks for C++17 Standard Library features > * make a couple of C++20 features mandatory (see below) > > Of the C++20 features I currently see a good reason to make mandatory: > * feature-test macros (no change: we're already using them) > * spaceship operator and <compare> header > * char8_t > * std::is_constant_evaluated() > * constinit > * <bit> header > * (maybe) designated initialisers > * (maybe) constexpr from <algorithm> and <utility> > > I'm not proposing modules, concepts or coroutines be allowed in our code just > yet. I think concepts will be the first of those, but we need to understand > how > to use them first and how our code will change. I'd love to require > std::format > and std::source_location, but those don't seem to be ready in the proposed > versions above. > > For this, I'd also like to request we raise our minimum compiler versions to: > * GCC 10 (released May 2020) > * Clang 10 (released March 2020) > * MSVC 2022 that is current today > * XCode that is current today > > Clang and GCC will be, at the time of Qt 6.7's release, just under 4 years > old. That should be enough to have been included in any long-term support > Linux distribution. Currently, both SLE 15.4 and RHEL/RockyLinux 9 have GCC > 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian will > probably release its next stable before Qt 6.7, though whether it'll still > upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum > of GCC 8 was of a lower age, at 2.5 years, so we could reasonably bump our > minimum GCC to 11 and still be 6 months more lenient. There are no new > features in GCC 11 that we could use without also requiring a more recent > Clang. > > Speaking of Clang, I simply chose a contemporaneous version and one that had a > similar feature list. FreeBSD 13-STABLE (13.2) comes with Clang 14, which is > much newer. We could raise the minimum if we wanted, but the intersection of > features with GCC 10 or 11 doesn't change much; we get std::bit_cast with > Clang/libc++ 14, but that's about it. > > This proposal also drops MSVC 2019 and assumes that users of 2022, like XCode, > keep their compilers reasonably up-to-date. That is, that they'll update to > the latest at least once in the next 10 months. > > I don't have access to QNX and INTEGRITY toolchain information, so I'd like to > request that they simply match the feature list above, with minimal > workarounds. > > Opinions? > > -- Marc Mutz <marc.m...@qt.io> Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
