Part 1: Analysis and Persona Adoption

Domain: Systems Software Engineering / Language Specification & Standards Persona: Principal Software Architect and C++ Language Specialist Tone: Technical, precise, authoritative, and strictly objective.

Part 2: Objective Summary of the Chromium C++ Style Guide

Abstract: This document defines the technical constraints and permitted features for C++ development within the Chromium project. It establishes a rolling support window for language standards (C++11 through C++23) and the Abseil library, prioritizing toolchain stability, binary size, and security over immediate adoption of new syntax. The guide serves as a central authority for developers to determine which modern C++ features are "allowed," "banned," or "to be determined" (TBD). It specifically emphasizes the rejection of standard features that overlap with Chromium’s //base library or introduce undesirable runtime behaviors, such as exceptions and RTTI-dependent components.

Key Technical Takeaways & Feature Status:

• Standard Support Lifecycle:
  • Initial Support: Features are banned by default for a two-year discussion period once a toolchain supports a new standard.
  • Default Allowed: Standards through C++17 are generally allowed, with specific exceptions. C++20 is in active transition (Initially supported Nov 2023); C++23 is slated for Jan 2026.
• Banned C++11/14/17 Language & Library Features:
  • Exceptions: Strictly banned. All code must be exception-safe; noexcept is permitted.
  • Smart Pointers: std::shared_ptr and std::weak_ptr are banned due to extrinsic reference counting. Developers must use base::RefCounted or base::WeakPtr.
  • Functional/Binding: std::bind and std::function are replaced by base::Bind and base::OnceCallback/RepeatingCallback for better lifetime and thread-safety management.
  • Time: <chrono> is prohibited in favor of base::Time.
• C++20 Implementation Status:
  • Allowed: Concepts/Constraints, Three-way comparison (<=>), Designated initializers, consteval, and std::erase_if.
  • Banned: char8_t (to avoid cast-heavy code), Modules (insufficient toolchain support), and std::span (superseded by base::span).
• C++23 Initial Trajectory:
  • Allowed: #elifdef, std::basic_string::contains, and std::byteswap.
  • TBD: std::expected, std::flat_map, and monadic optional operations are currently under review.
• Abseil Library Constraints:
  • General Rule: Allowed where it does not overlap with //base.
  • Banned: absl::any and absl::StatusOr (due to RTTI requirements), absl::Mutex (use base/synchronization), and absl::Random (uses non-cryptographically secure generators).
• Third-Party Code Policy:
  • Third-party libraries may use banned features internally. However, Chromium-side interfaces must convert banned types to allowed equivalents as soon as practical.

Part 3: Reviewer Group Identification and Contextual Summary

Review Group: The Chromium C++ Style Arbiters & Clang Toolchain Team This group consists of senior engineers responsible for the project's technical debt, compiler performance, and the maintainability of the multi-million-line codebase. They bridge the gap between "standard C++" and "Chromium C++."

Summary from the Perspective of the Style Arbiters:

"Our primary mandate is maintaining the stability of a 35-million-line codebase where 'standard' doesn't always mean 'optimal.' Our current roadmap focuses on the cautious integration of C++20/23 while aggressively pruning features that threaten binary size or security.

• The 'Base' vs. 'Standard' Conflict: We acknowledge the community's observation that we frequently ban STL features (e.g., <chrono>, std::function). These aren't arbitrary bans; they are necessary to prevent fragmentation. If we have a proven, thread-safe base::Callback, allowing std::function introduces risk without reward.
• The Exception Hardline: As noted in the external discourse, our ban on exceptions is a historical and structural necessity. Transitioning a codebase of this scale to be exception-safe is practically impossible. We use noexcept to aid optimization but rely on explicit error handling for stability.
• The char8_t and Modules Rejection: We've banned char8_t because the 'standard' approach would force a cascade of casts across our existing string APIs. Similarly, Modules remain banned not because we dislike the feature, but because Clang and GN support are not yet performant enough for a build of our magnitude.
• Abseil Integration: We are effectively using Abseil as a backport library. Where Abseil provides a feature that will eventually be in the C++ standard (and doesn't require RTTI), we allow it. Where it replicates base/, we block it to maintain a single way of doing things.
• Efficiency over Novelty: Our priority is the 'Happy Path'—keeping the compiler fast and the binary lean. If a new C++23 feature like std::expected can eventually replace our internal templates without a code-size penalty, we will move it from TBD to Allowed."