Re: [Development] About the timeline and phases to support C++20 with and in Qt
From what I see, the open questions from the thread in May are still: - (paraphrasing Ville) which C++ 20 features are worth breaking (primarily embedded) users who want new Qt version but don’t yet have the compilers that can give them these facilities? https://lists.qt-project.org/pipermail/development/2023-May/043887.html And the perspective here needs to be the users of Qt. In Qt, we can often work around missing facilities, if there is a real benefit in doing so. But as long as users can use a more recent C++ language standard for their code without being hobbled by Qt, the list of C++20 features that really would make a difference for Qt users seems to negligible. From what I see, we are years away from doing anything useful with modules and co-routines, as the two biggest items that users of Qt would be interested in and ask about. Have we done any work on any of those, beyond Ville’s work on senders & receivers? Concepts would be very useful, also for Qt users, because a library of concepts could be useful for users when they create their own APIs; and because it would allow us to comprehensibly document the requirements for our own templates (today we often hide the std::enable_if’ery from documentation, and don’t always provide equivalent information about the requirements to the types used in our templates). We can perhaps start with that as a documentation feature (qdoc can use libclang with whatever C++ standard it wants). - which C++ standard do the oldest versions of gcc and clang we support default to (the gcc devs at least strongly advising against explicitly raising the language version from the default) https://lists.qt-project.org/pipermail/development/2023-May/043915.html https://gcc.gnu.org/projects/cxx-status.html still documents C++20 as experimental, and C++17 as the default. Volker On 5 Feb 2024, at 10:57, Alex Blasche via Development wrote: Hi, For Qt 6.8 we continue to work on Phase 1 item https://bugreports.qt.io/browse/QTBUG-109360. In other words we will not mandate C++20 compilers in Qt 6.8 yet. An LTS release is not the right for such a breaking change anyway. The possible releases for such a drastic change are 6.9 or 6.12 (releases immediately following an LTS release). Note that I am not cofirming those releases but merely point out which type of releases could be potential options. Considering the track record we have when getting Phase 1 items into the release and considering existing customer concerns I have a hard time believing that 6.9 is a serious option. This is my personal opinion. -- Alex From: Development on behalf of Thiago Macieira Sent: Saturday, 3 February 2024 18:13 To: development@qt-project.org Subject: Re: [Development] About the timeline and phases to support C++20 with and in Qt On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development wrote: We got four user stories on Qt Bug Reports: 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 2. C++20 is required for the development of Qt itself - https://bugreports.qt.io/browse/QTBUG-109361 3. C++20 is mandatory for users of Qt - https://bugreports.qt.io/browse/QTBUG-109362 Those tasks haven't got any updates recently. What's the status? I'd like to ask that we go to #3 for 6.8 or 6.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
Hi, For Qt 6.8 we continue to work on Phase 1 item https://bugreports.qt.io/browse/QTBUG-109360. In other words we will not mandate C++20 compilers in Qt 6.8 yet. An LTS release is not the right for such a breaking change anyway. The possible releases for such a drastic change are 6.9 or 6.12 (releases immediately following an LTS release). Note that I am not cofirming those releases but merely point out which type of releases could be potential options. Considering the track record we have when getting Phase 1 items into the release and considering existing customer concerns I have a hard time believing that 6.9 is a serious option. This is my personal opinion. -- Alex From: Development on behalf of Thiago Macieira Sent: Saturday, 3 February 2024 18:13 To: development@qt-project.org Subject: Re: [Development] About the timeline and phases to support C++20 with and in Qt On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development wrote: > We got four user stories on Qt Bug Reports: > > 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 > 2. C++20 is required for the development of Qt itself - > https://bugreports.qt.io/browse/QTBUG-109361 > 3. C++20 is mandatory for users of Qt - > https://bugreports.qt.io/browse/QTBUG-109362 Those tasks haven't got any updates recently. What's the status? I'd like to ask that we go to #3 for 6.8 or 6.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
On 03.02.24 18:13, Thiago Macieira wrote: > On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development > wrote: >> We got four user stories on Qt Bug Reports: >> >> 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 >> 2. C++20 is required for the development of Qt itself - >> https://bugreports.qt.io/browse/QTBUG-109361 >> 3. C++20 is mandatory for users of Qt - >> https://bugreports.qt.io/browse/QTBUG-109362 > > Those tasks haven't got any updates recently. What's the status? > > I'd like to ask that we go to #3 for 6.8 or 6.9. We don't drop supported compilers except in LTS+1 releases. That means 6.9 at the earliest. In the last round, these were the objections: a. QNX and Integrity don't support it, yet b. We'd like to avoid forcing users to switch their projects to C++20, which is the rationale for separating (2) and (3) above. I think (a) is a blocker, unless we allow different platforms to have different minimum C++ version requirements. That won't help with whatever you're thinking about when you ask to require C++20, because it means we'll need to maintain C++17-compatibility in the vast majority of the code-base. I have some sympathy for (b), and I could live with the required #ifsef'ery for the time being, because it would be something that's required for (public) headers only. Jani, Vladimir: do we have line-of-sight for C++20 support in QNX, Integrity, VxWorks and WebAssembly? Thanks, Marc -- Marc Mutz 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
Re: [Development] About the timeline and phases to support C++20 with and in Qt
On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development wrote: > We got four user stories on Qt Bug Reports: > > 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 > 2. C++20 is required for the development of Qt itself - > https://bugreports.qt.io/browse/QTBUG-109361 > 3. C++20 is mandatory for users of Qt - > https://bugreports.qt.io/browse/QTBUG-109362 Those tasks haven't got any updates recently. What's the status? I'd like to ask that we go to #3 for 6.8 or 6.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
On Thursday, 4 May 2023 06:48:55 PDT Volker Hilsheimer via Development wrote: > But those that can and do upgrade their toolchain regularly might just as > well upgrade to something fairly recent whenever they do that. Between 6.8 > branching (the last LTS only requiring C++17, as per current plan) and 6.11 > (the next LTS after that, if we stick to the current cadence), we and > compiler vendors have another 18 months to work on the C++23 feature set. > Why would we not want to start using some C++23 features with 6.11 (in > H1/26, presumably)? Even if it’s only a subset of the standard - what we > document is the compiler versions we support, and we have to limit > ourselves mostly to the common denominator anyway. Because I'm being told in the same breath that "4-year-old compilers are too recent" when the C++20 update in March 2024 and LTS in September 2024 is not acceptable. Therefore, for a release in March 2025 and LTS in March 2026, requiring compilers released in 2023 is too recent too. Please give me a number: how old must a compiler be for it to be acceptable to require compilers to have updated to it or more recent than it? We could use C++23 features in 2025 that were supported in 2020 compilers. I'm just arguing that there aren't any that are worth the trouble. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
> On 3 May 2023, at 19:20, Thiago Macieira wrote: > On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote: >> However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller >> challenge for compiler vendors to support after C++20. If we stick to the >> timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025, >> then perhaps we should skip C++20 and immediately require C++23. People >> that can move to a C++20 toolchain in 2025 can perhaps just as well move to >> a C++23 toolchain at that point. That needs more investigation, of course. >> But given the inevitable pain that comes with changing minimum >> requirements, moving to a standard that is already 5 years old seems a bit >> wasteful. > > My opinion on C++23 reasonable features we'd like to use without workarounds: > * if consteval - not supported by current MSVC > * deducing this - not supported by any current compiler > * [[assume]] - we could use this now, https://codereview.qt-project.org/462807 > * - requires GCC 13 or LLVM libc++ 16 > > So my opinion is that aiming for C++23 is not possible for 6.9. For a release > in March 2025, the interesting features are too recently supported or can be > used without C++23 in the first place. The same goes for the next set of > features from C++20 I'd like us to explore ( with GCC 13; > std::source_location with libc++ 16, etc.). At best, we'd have the exact same > feature set I proposed for C++20, except we'd compile with -std=c++23. > > So, no, I think we should aim for the feature set I posted yesterday from > C++20. The question is only when. My thinking and assumption is: those users that don't upgrade their toolchain to something recent are also (typically) the users that stay on the latest LTS release. That will be Qt 6.8; what we do in 6.9 and 6.10 and until 6.11 LTS is of limited interest to those users. The C++ standard is just one aspect to this. But those that can and do upgrade their toolchain regularly might just as well upgrade to something fairly recent whenever they do that. Between 6.8 branching (the last LTS only requiring C++17, as per current plan) and 6.11 (the next LTS after that, if we stick to the current cadence), we and compiler vendors have another 18 months to work on the C++23 feature set. Why would we not want to start using some C++23 features with 6.11 (in H1/26, presumably)? Even if it’s only a subset of the standard - what we document is the compiler versions we support, and we have to limit ourselves mostly to the common denominator anyway. For non-LTS releases (or the first after the LTS, i.e. 6.9), we might want to bump the minimum compiler versions to something that's not older than 18 months (we can argue over that), and we stick to those versions until the following LTS release, one year later. And assuming that by H1/2025 there is a common subset of the C++23 standard that all compilers support, why would we not use those features? Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
Thiago Macieira (3 May 2023 19:20) wrote: > I don't see us adopting Modules any time soon, not even for the 6.9 > release. It's not well supported *today*. Also, they're a radical change to how source is organised and it "might not be a bad idea" to wait until the C++ world has developed some common practices in how to use them, and maybe even some best practices, so that however we go about using them can conform to the latter as far as is compatible with the former. That won't happen until support has been commonplace for long enough for (preferably other) people to make the mistakes that will establish the antipatterns that will inform the development of both common and best practices. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote: > The standing proposal is to move to C++20 with Qt 6.9, after the next LTS > release. I see no pressing reasons to accelerate that. The value of the > features Thiago listed - which excludes all the big stuff anyway - doesn’t > seem so significant that it outweighs the impact on the community of users > that are stuck on C++17, for a variety of reasons that we can’t just shrug > off. The big stuff you're talking about are Modules and co-routines. I don't see us adopting Modules any time soon, not even for the 6.9 release. It's not well supported *today*. Co-routines we'd need to learn how to make good use of them and we won't until we begin using them, so postponing buys us little. That leaves concepts, which I think we could begin rolling in slowly. According to https://en.cppreference.com/w/cpp/20, the core language support appears to be there for the compilers versions I called out for, but not the concepts library for libc++. Upping the requirement for libc++ might be an acceptable compromise once we learn what we want to do with concepts. > However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller > challenge for compiler vendors to support after C++20. If we stick to the > timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025, > then perhaps we should skip C++20 and immediately require C++23. People > that can move to a C++20 toolchain in 2025 can perhaps just as well move to > a C++23 toolchain at that point. That needs more investigation, of course. > But given the inevitable pain that comes with changing minimum > requirements, moving to a standard that is already 5 years old seems a bit > wasteful. My opinion on C++23 reasonable features we'd like to use without workarounds: * if consteval - not supported by current MSVC * deducing this - not supported by any current compiler * [[assume]] - we could use this now, https://codereview.qt-project.org/462807 * - requires GCC 13 or LLVM libc++ 16 So my opinion is that aiming for C++23 is not possible for 6.9. For a release in March 2025, the interesting features are too recently supported or can be used without C++23 in the first place. The same goes for the next set of features from C++20 I'd like us to explore ( with GCC 13; std::source_location with libc++ 16, etc.). At best, we'd have the exact same feature set I proposed for C++20, except we'd compile with -std=c++23. So, no, I think we should aim for the feature set I posted yesterday from C++20. The question is only when. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
Bumping this thread up in your inboxes as it includes the links to the JIRA tickets where the journey towards C++20 has been planned and discussed so far. Let's try to build on what we already know. The standing proposal is to move to C++20 with Qt 6.9, after the next LTS release. I see no pressing reasons to accelerate that. The value of the features Thiago listed - which excludes all the big stuff anyway - doesn’t seem so significant that it outweighs the impact on the community of users that are stuck on C++17, for a variety of reasons that we can’t just shrug off. However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller challenge for compiler vendors to support after C++20. If we stick to the timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025, then perhaps we should skip C++20 and immediately require C++23. People that can move to a C++20 toolchain in 2025 can perhaps just as well move to a C++23 toolchain at that point. That needs more investigation, of course. But given the inevitable pain that comes with changing minimum requirements, moving to a standard that is already 5 years old seems a bit wasteful. Volker > On 21 Dec 2022, at 18:51, Vladimir Minenko via Development > wrote: > > Hello all, > > I want to share on this mailing list a proposal for the timeline and phases > to support C++20 with and in Qt. Writing this, I’m aware that there were > other discussions about the support of C++20 on this mailing list. This > message is a step to get a list of features that all Qt users can expect > along a certain timeline. We want to make the landing with the adoption of > new C++ standards “softer” than it used to happen in the past, yet prompt > enough to make sure that Qt keeps and enlarges its popularity among C++ > developers. > > We got four user stories on Qt Bug Reports: > > 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 > 2. C++20 is required for the development of Qt itself - > https://bugreports.qt.io/browse/QTBUG-109361 > 3. C++20 is mandatory for users of Qt - > https://bugreports.qt.io/browse/QTBUG-109362 > 4. Long term: C++23, Qt7, and unsorted - > https://bugreports.qt.io/browse/QTBUG-109363 > > These user stories are linked to selected features from the list once created > by Marc in https://bugreports.qt.io/browse/QTBUG-99243 > > The above list is sorted in the order of time. Still, a particular "Fix > Version” is not set yet. We (all) have to set this, though. ASAP for #1, and > by the time we ship the version set in #1, we should set the version for #2, > etc. See the list of all releases at > https://wiki.qt.io/QtReleasing#Qt_releases > > In addition, there is a task https://bugreports.qt.io/browse/QTBUG-109469 to > add a new page or extend an existing page (Supported Platforms?) with details > about the support of C++ standards. Plus, we need to get a simple way to test > the capabilities of a toolchain, see > https://bugreports.qt.io/browse/QTBUG-109470. > > The latter should be a help mainly for Qt users on embedded platforms. Those > folks have serious problems again and again with "fast moves” towards new C++ > standards since they do not have the luxury of quick updates of compilers and > standard libraries as known on desktops. > > Please have a look at the above issues, comment on Qt Bug Reports, and make > changes if applicable. > > And now, the most important point ;-) - Merry Christmas and Happy New Year! > > -- > Vladimir Minenko > vladimir.mine...@qt.io > +49 171 90 61 461 > > Senior Product Manager, Qt Foundation > The Qt Company - https://qt.io > > c/o Regus / Josephspitalstraße 15 > 80331 Munich, Germany > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] About the timeline and phases to support C++20 with and in Qt
Hello all, I want to share on this mailing list a proposal for the timeline and phases to support C++20 with and in Qt. Writing this, I’m aware that there were other discussions about the support of C++20 on this mailing list. This message is a step to get a list of features that all Qt users can expect along a certain timeline. We want to make the landing with the adoption of new C++ standards “softer” than it used to happen in the past, yet prompt enough to make sure that Qt keeps and enlarges its popularity among C++ developers. We got four user stories on Qt Bug Reports: 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 2. C++20 is required for the development of Qt itself - https://bugreports.qt.io/browse/QTBUG-109361 3. C++20 is mandatory for users of Qt - https://bugreports.qt.io/browse/QTBUG-109362 4. Long term: C++23, Qt7, and unsorted - https://bugreports.qt.io/browse/QTBUG-109363 These user stories are linked to selected features from the list once created by Marc in https://bugreports.qt.io/browse/QTBUG-99243 The above list is sorted in the order of time. Still, a particular "Fix Version” is not set yet. We (all) have to set this, though. ASAP for #1, and by the time we ship the version set in #1, we should set the version for #2, etc. See the list of all releases at https://wiki.qt.io/QtReleasing#Qt_releases In addition, there is a task https://bugreports.qt.io/browse/QTBUG-109469 to add a new page or extend an existing page (Supported Platforms?) with details about the support of C++ standards. Plus, we need to get a simple way to test the capabilities of a toolchain, see https://bugreports.qt.io/browse/QTBUG-109470. The latter should be a help mainly for Qt users on embedded platforms. Those folks have serious problems again and again with "fast moves” towards new C++ standards since they do not have the luxury of quick updates of compilers and standard libraries as known on desktops. Please have a look at the above issues, comment on Qt Bug Reports, and make changes if applicable. And now, the most important point ;-) - Merry Christmas and Happy New Year! -- Vladimir Minenko vladimir.mine...@qt.io +49 171 90 61 461 Senior Product Manager, Qt Foundation The Qt Company - https://qt.io c/o Regus / Josephspitalstraße 15 80331 Munich, Germany ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
