[Development] Raising the minimum to C++20

[Thiago Macieira]

On Wednesday, 3 May 2023 11:14:55 PDT Marc Mutz via Development wrote:
> [Sorry, yes, 6.9 is in spring '25. I messed up the counting]

As a native of the Southern Hemisphere, I ask that we use dates, not seasons 
to refer to times. Everyone knows that Spring happens in September, right 
before we go for Christmas and New Year at the beach for some suntan.

I also make a similar request of any Americans around: spell out you month 
names, so there's no mistaking whether "04/05/2023" means First Contact Day 
(Star Trek) or May The Fourth Day (Star Wars). Or use ISO dates.

> 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.

Agreed: if the toolchain they're using can compile Qt in C++20 mode, then that 
toolchain can compile their application too. So long as the update of the 
toolchain retains compatibility with code that had been previously compiled, 
there aren't any major issues. All of the ones I work with do.

There may be a bit of code that compiled with C++17 and doesn't with C++20 
(like the implicit capture of this in [=]), but they're usually simple and 
easy to fix. 

There may also be issues with some other libraries that, unlike Qt and the 
Standard Libraries, do have different symbols depending on whether they were 
compiled with C++17 or 20 (e.g., an out-of-line operator<=>). Those would need 
to be recompiled with the new toolchain. Usually, vendors that have bothered 
with writing C++20 code would have such builds available, so I don't expect 
this need to be a big problem either.

But those are paper cuts. If you add enough of them...

> > 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.

Indeed, see my reply to Volker in the older thread. I don't see anything in 23 
that we'd push for.

And yet, the list of things we want from C++20 is not that big. It's nowhere 
as complex as C++11 and I'd argue that even the 17 upgrade for Qt 6.0 was a 
bigger jump. Unless we add concepts to the list, but I don't think we can 
until we've experimented with it for a while.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230503/a3e6f6d8/attachment-0001.bin>