C++20 is now allowed in Chromium

[Peter Kasting]

If you do not write C++ in Chromium you can ignore this message.

TLDR: C++20 is now formally allowed. See the features list for what you can and cannot use. To request a feature status change, email c...@chromium.org.

Longer version follows

As of today, first-party code in Chromium is allowed to use C++20 language and library features. Unlike with past version upgrades where initially few (or no) new features were allowed, we are allowing a significant number of features immediately; see the Modern C++ features list for complete details, but the most significant allowed features are:

• Concepts, which make template definitions more readable and faster to compile
• Defaulted comparison operators and the <=> ("spaceship") operator, which simplify writing value types
• Member initializers for bitfields, like other member types
• <bit>, which can replace various parts of base/bits.h
• <numbers>, which can replace various parts of base/numerics/math_constants.h
• std::erase[_if], which can replace base::Erase[If]
• std::lerp and std::midpoint, which can be useful for UI
• std::string::(starts,ends)_with, which can replace base::(Starts,Ends)With

Some features you might have wanted are disallowed or TBD:

• Modules, which need further toolchain (including gn) support and a migration plan
• Ranges, which cause compile time concerns (among others); use base/ranges/algorithm.h
• Coroutines, which need significant local support and a migration plan
• <span>, which does not make use of MiraclePtr; use base::span
• <format>, which is not backwards-compatible with printf-style strings and does not support std::u16string; use base::StringPrintf
• <source_location>, which seems to regress code size; use base::Location
• std::u8string, a string type which is explicitly UTF-8; use std::string

If you wish to debate any feature classifications or propose allowing a TBD feature, email c...@chromium.org.

FAQ:

• Are there any downsides of this change?
• Changing to C++20 caused both binary sizes and compile times to increase, in part because more STL types and APIs are constexpr (and inlineable). We made these changes beginning around a year ago and determined that the regressions were acceptable. (That said, I'd love if someone investigated improving inlining decisions around constexpr code in Chromium's build context...)
• What about third-party code?
• We don't restrict third-party use of C++20 beyond "it has to still work in our build". However, some third-party code, such as PDFium, may not yet allow C++20. Also, ChromeOS code outside Chromium is not covered by this announcement.
• Will we be replacing base:: APIs with std:: ones?
• In some cases, yes, over time. The features list generally links to applicable migration bugs, and we welcome contributions. In a few cases, like <ranges> or std::span, future use of the std:: version is uncertain.
• When will we get C++23?
• We've generally allowed new language versions about three years after standardization. The delay is not due to caution as much as the necessary time for our toolchain to support the new spec and for us to fix any compilation issues. So if history is a guide, expect C++23 around 2026. That said, there is no central team or person who owns these transitions, so if you'd like to see something sooner, start trying to fix C++23 problems yourself :)
• Wait, we're still using C++? I thought Rust/Carbon/etc. was the future?
• While work to support and use Rust more broadly continues, we will still be using C++ in Chrome for the foreseeable future, and it makes sense to stay current with newer language specs. We will still be writing new C++ code five years out, and we will still be at least maintaining C++ code ten years out.

Thank Yous

This announcement has been a year and a half in the making, and in that time a huge number of people have been helpful. I'd like to extend special thanks to Hidehiko Abe for doing much of the technical work on ChromeOS, Dana Jensens for code reviews, moral support, and pushing to get the final approval flipped, Daniel Cheng for code reviews and expertise, Eric Lok for managing and driving the ChromeOS side, Nico Weber for ATL coordination and clang expertise, George Burgess for clang-tidy coordination, Christopher Di Bella for stability data and Google-side coordination, Rob Liao and Rachel Blum for steady management-side support, and anyone who wrote or reviewed C++20-related changes or contributed to the discussion around them. I appreciate you.

PK