Chromium's C++ Evolution: A Conservative Path Through Modern Standards

Chromium's relationship with modern C++ is defined by patience rather than enthusiasm. The project's C++ style guide reveals a systematic, almost bureaucratic approach to language adoption that prioritizes stability over cutting-edge features. Unlike many open-source projects that eagerly embrace new standards, Chromium treats each C++ version as a potential disruption requiring careful evaluation.

The process begins with toolchain readiness. When Chromium's build system can support a new standard—C++20 was declared "initially supported" on November 13, 2023, and C++23 will follow in January 2026—features aren't automatically allowed. Instead, they enter a "TBD" (to be determined) status where they remain banned pending discussion. This creates a two-year window for evaluation. If a feature sits on the TBD list for two years without resolution, style arbiters must explicitly move it to either an allowlist or blocklist.

This conservative stance manifests in surprising ways. Despite C++11 being over a decade old, Chromium still bans several of its features. The std::shared_ptr and std::weak_ptr smart pointers are prohibited, as are the entire Thread Support Library (<thread>, <mutex>, <condition_variable>) and even the <chrono> time library. The reasoning isn't about technical merit but about Chromium's unique constraints: the project must maintain compatibility across multiple platforms, compilers, and build configurations, and some standard library features introduce performance, security, or portability concerns.

The guide's extensive banned lists read like a catalog of C++ features that other projects embrace without hesitation. C++17's std::filesystem, std::any, and std::byte are all banned. Even C++20's <span> and std::bit_cast—features designed for safer, more efficient code—are prohibited. The pattern suggests Chromium's maintainers have learned hard lessons about the cost of standard library dependencies, particularly around cross-platform consistency and binary size.

Where Chromium does allow modern features, the selection is telling. C++20's concepts and constraints are permitted, enabling better template error messages and compile-time validation. The three-way comparison operator (<=>) is allowed, offering a cleaner way to define comparison semantics. Designated initializers make struct initialization more readable. These features are permitted because they improve code clarity and safety without introducing runtime dependencies or portability concerns.

The Abseil library presents a parallel story. While Chromium's own code is restricted, third-party libraries can use banned features internally—provided they don't leak into Chromium's interfaces. This creates an interesting boundary where std::shared_ptr might be used inside a library but must be converted to raw pointers or Chromium's own smart pointer types at the API boundary. The guide explicitly notes that if a third-party library requires banned types for its interface, developers should discuss workarounds with the [email protected] mailing list.

Abseil itself faces similar restrictions. Despite being Google's own C++ library, many of its components are banned in Chromium code. absl::StatusOr, absl::optional, absl::string_view, and absl::Span—all precursors to standard library features—are prohibited. This suggests Chromium's maintainers prefer to wait for standardization rather than commit to Abseil's evolving APIs, even when they come from the same organization.

The guide's TBD list reveals features under active consideration. C++20 coroutines and <format> remain in limbo, as do C++23's std::expected and std::generator. These features face the classic trade-off: coroutines could simplify async code but introduce compiler complexity and potential performance variations; <format> offers safer string formatting but adds another library dependency. The two-year review period forces developers to justify not just the feature's utility but its long-term maintainability.

For developers working in Chromium, this creates a distinctive coding environment. They must navigate a landscape where std::vector is allowed but std::erase_if (C++20) is banned; where std::unique_ptr is permitted but std::make_unique_for_overwrite is not; where lambda captures can use pack expansions but coroutines cannot. The style guide becomes a living document, updated through email discussions and code reviews rather than top-down mandates.

This approach reflects Chromium's scale and complexity. With millions of lines of code, dozens of platforms, and thousands of contributors, the cost of a problematic language feature—whether through compiler bugs, performance regressions, or portability issues—outweighs the benefits of early adoption. The guide's conservative stance isn't about resisting progress but about managing risk in a codebase that powers one of the world's most widely used software platforms.

The result is a C++ dialect that's modern in some respects but deliberately conservative in others. It's a pragmatic approach that prioritizes the project's stability over the language's evolution, creating a unique ecosystem where even decade-old features remain controversial.