MSVC’s STL Completes /std:c++20
Casey Carter
We are happy to announce that the final C++20 Standard Library features are now stabilized and available in /std:c++20 mode in both Visual Studio 2022 version 17.2 and Visual Studio 2019 version 16.11.14. This notably includes several proposals approved as Defect Reports (DRs) by the C++ Standard Committee against the C++20 Standard Library that made extensive design changes to <format> and <ranges> as recently as October 2021. You can now use the complete list of C++20 features in production in a binary compatible way with other supported language version modes.
C++20 Complete… Again??!?
We previously announced that MSVC had completed all features in C++20 for Visual Studio version 16.11.0, and that we had added the /std:c++20 option to indicate that most C++20 features were stabilized and considered production-ready. We delayed making some library features (<format>, <ranges>, and the portions of <chrono> that use <format>) available under /std:c++20 since there were substantial and important changes in the works for those features in the Standard Committee. We didn’t want to release those features in their current form and later apply changes that would break users of /std:c++20. Those features continued to be available only under /std:c++latest while the Committee finalized the changes and we implemented them.
Defect Reports
The DRs include both source and ABI-breaking changes to features in <format> and <ranges>. The amazing community of contributors that has grown up around the STL since open-sourcing has been implementing the DRs in the Visual Studio 2022 release series under /std:c++latest just as if they were C++23 features. Our plan has been to make the final result available under /std:c++20 once all the DRs are done, and then backport that work to Visual Studio 2019 to complete the C++20 story for customers who haven’t yet moved to Visual Studio 2022. We accomplished the first goal for Visual Studio 2022 17.2 Preview 2.
The backporting work went miraculously well considering that we had to merge a hundred commits from the development branch into the 16.11 release branch and get everything working without regressing that stable release series. We managed to complete the work in time to ship the 16.11 C++20 backport simultaneously with the completion of C++20 support in 17.2.
Go Ye Forth And Code
We’re happy to make these last bits of C++20 available to customers who need production stability guarantees. Please let us know about any problems or questions you have with the C++20 support in either Visual Studio 2019 version 16.11.14 or Visual Studio 2022 version 17.2, either via the STL’s GitHub issue tracker, Developer Community, or commenting below.
Light
Dark
5 comments
Congrats! Great work in getting this out so soon.
These are very good news 🎉
I am delighted to read this, but I don’t quite understand the ABI and backport messaging. You say that there have been ABI breaking changes to features in format and ranges. Does this mean there has been an ABI break at 16.11 and 17.2? Or were the changes delayed until there would be no ABI break necessary? Will I be able to use all features of C++20 without enduring an ABI break?
To be precise: the ABI of some library features in 16.11.13 that were only available with /std:c++latest changed in 16.11.14 as we pulled them into /std:c++20 “stable” territory. We don’t guarantee source or ABI stability for /std:c++latest since it’s all Work In Progress, but our “real” /std:c++XX language mode flags try very hard to avoid breaking changes, and we basically don’t make ABI-breaking changes, even when that means bugs sit unfixed. We’ll eventually break ABI again, but only in a very noisily planned way – probably at a major release boundary.
TLDR: Nothing previously declared stable (/std:c++20 or earlier language modes) had breaking changes, but if you were using “experimental” (/std:c++latest) things that are now /std:c++20 things you will likely see ABI and source-breaking changes.
Glad it ended up in VS2019. C++20 is quite a big improvement with e.g. ranges; default comparison operators; three way comparison; format library and span. coroutines is probably never used by us. modules is a revolutionary addition but with our code base of 3000+ files this is probably never going to happen. I preferred they improved the build times of the traditional header system e.g. by skipping pre-processor phases or expansive template constructs.