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
