[Development] Raising the minimum to C++20

[Marc Mutz]

On 03.05.23 18:24, Thiago Macieira wrote:
> On Tuesday, 2 May 2023 22:51:02 PDT Marc Mutz via Development wrote:
>> 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).
> 
> We are after an LTS release (6.5). We could have done this for 6.6 and had the
> same ages for the compilers as 6.0 did, but it's too soon. So 6.7 sounds good.

We couldn't've done this for 6.6, because Integrity isn't there, yet.

>> 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.
> 
> I personally think that a March 2025 release is late. I'd like to pull that
> in. But since I don't think the 6.8 release will be acceptable, we get only
> the March 2024 release as another option.

[Sorry, yes, 6.9 is in spring '25. I messed up the counting]

>> 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.
> 
> Qt 6.5 was released March 2023. If it's supported for 3 years for those
> customers, they have until March 2026 to upgrade. Is that so bad? (Honest
> question)

I'm not the one talking to these customers, but the feedback I get from 
those who do is that yes, it's too early. Then again, the internal plan 
calls for requiring C++20 for building (but not using) Qt 6.9. I don't 
see how that helps any user. If they can build Qt in C++20 (or arrange 
for it to be built for them), then they can build their own project in 
C++20, too. I get the desire to insulate users from having to port their 
own code to C++20, but as I said, I don't see how that's possible to 
avoid if Qt itself must be built with C++20.

Maybe TQtC needs to open the VLTS branches up a bit more, to allow a bit 
more risky kinds of backports than currently, to appease users stuck on 
these versions due to toolchain issues, but from a Qt OSS project POV, I 
don't think it's something we need to care about. That is what customers 
pay money for to TQtC, so it's TQtC's decision how to deal with this.

>> 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.
> 
> If you're only going to make a VLTS release every 4.5 years, then we won't be
> able to adopt every C++ release. C++23 may be too soon for adoption in late
> 2024 (release March 2025), but we may then skip C++26 for the one after.

C++20 (like C++11) are a bit special as they're rather large releases. 
Companies and customers may be (rightfully) more reluctant to upgrade to 
C++20 than they were from, say, 11 to 14, which is what I expect 20-23 
to feel like.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at 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