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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to