1. Banning Features Due to Historical Constraints and Codebase Specificity
Many participants argue that the banned list is not about the features' inherent quality but stems from Google's massive legacy codebase and monolithic repository. Using a standard library feature would be impractical if an older, proprietary alternative already exists and is deeply integrated. This is often viewed as a form of "Not Invented Here" (NIH) syndrome or a pragmatic necessity for uniformity in a giant project.
- Night_Thastus: "Nothing particularly notable here. A lot of it seems to be 'We have something in-house designed for our use cases, use that instead of the standard lib equivalent'."
- dmoy: "There's some massive NIH syndrome going on. Another piece is that a lot of stuff that makes sense in the open source world does not make sense in the context of the giant google3 monorepo with however many billions of lines of code all in one pile."
- dfajgljsldkjag: "The banned list proves that context matters more than having the newest tools. These features work well for small apps but they cause problems in a project this size."
2. The Exception Handling Debate: Practicality vs. Robustness
The ban on C++ exceptions is a major point of contention. Participants are divided. One side defends the ban on practical grounds: Google's existing code is not exception-safe, and retrofitting them is too costly. The other side argues that exceptions are a superior error-handling mechanism to error codes, offering better safety and cleaner code separation, especially when using modern language constructs (like std::expected).
- pjmlp (quoting the guide): "Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had to do it all over again from scratch."
- jandrewrogers: "In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability."
- kllrnohj: "If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit. Exceptions are more robust, not less."
3. The char8_t Controversy and C++ Portability
The discussion reveals a deep skepticism about the utility of the char8_t type introduced in C++20. Critics argue its design is flawed, as it's not truly 8-bit guaranteed and is incompatible with existing APIs, forcing casts everywhere. The debate extends to the broader question of whether C++ should prioritize support for esoteric, non-8-bit-byte platforms at the expense of simplicity for the vast majority of users.
- vitaut (quoting the guide): "Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t is not interconvertible with char... so using u8 prefixes would obligate us to insert casts everywhere."
- 20k: "char8_t also isn't guaranteed to be 8-bits, because sizeof(char) == 1 and sizeof(char8_t) >= 1. On a platform where char is 16 bits, char8_t will be 16 bits as well. The cpp standard explicitly says that it has the same size, typed, signedness and alignment as unsigned char, but its a distinct type. So its pretty useless, and badly named."
- LexiMax: "Is there a single esoteric DSP in active use that supports C++20? ... It really does seem that trying to be the language for all possible and potential architectures might not be the right play for C++ in 202x."