Banned C++ features in Chromium

In-house libraries vs standard C++

• Many see Chromium’s bans as “use our in-house version instead of the standard one,” typical of old, large codebases that predate modern STL (chrono, containers, etc.).
• Some argue the long‑term optimum is migrating to standard types that new hires already know; others say deep integration with internal components justifies sticking with internal libraries.
• There’s also a cultural angle: some organizations systematically reimplement everything (NIH), which only partly makes sense outside their monorepo context.

STL container quality and alternatives

• Several commenters think many std containers are poorly designed or overspecified (e.g., unordered_map, std::deque, std::vector<bool>) and that modern hash maps (like those in Abseil) are clearly superior.
• Others push back, claiming std containers are “good enough” for most software and criticizing repeated STL‑bashing.
• Bad homegrown containers can be far worse than STL, with anecdotes of opaque, void*-based “iterators” that destroyed safety and performance and were extremely costly to refactor away.

char8_t, character size, and portability

• Chromium bans char8_t with a rationale many agree with: almost all APIs use char*/std::string, so char8_t* just forces casts for little gain.
• Debate centers on C/C++’s guarantees: char and char8_t are 1 byte, but a “byte” need not be 8 bits; some mention exotic DSPs as a reason the standards remain so general.
• Several people call char8_t a blunder: distinct type, same layout as unsigned char, often not actually 8 bits, and confusingly named.

Exceptions ban and error handling

• Chromium (via Google style) bans exceptions for historical/practical reasons: huge legacy code not written to be exception‑safe. Even Google’s own docs say things might be different if starting from scratch.
• Long subthread debates whether C++ exceptions are inherently problematic (unstable, hard to reason about in low‑level code) or actually more robust than error codes (you at least get a clean crash).
• Alternatives discussed: explicit error returns, macros, std::expected-style types, Rust‑like Result, and Zig‑style error propagation. Some want checked exceptions; others point to Java’s mixed history here.

Scale, consistency, and banned‑feature culture

• Many see the ban list as context‑driven: features that are fine in small projects become hazards in a massive, long‑lived, highly portable codebase.
• Consistency and reduced cognitive load are recurring themes: avoiding “sporadic new features” and sticking to one way of doing things.
• Comparisons are made to Java/C#/Rust: they also have de facto or tool‑enforced “banned” APIs/features, but often at the library level rather than core language constructs.
• There’s interest in enforcing such bans via static analysis, compiler lints, or custom tools; other projects (e.g., WebKit) reportedly do similar things.