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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development