C++26 is done: ISO C++ standards meeting Trip Report

Original Article ↗ Hacker News Discussion ↗

C++26’s completion is met with mixed reactions: many welcome features like reflection, contracts, and execution primitives, but argue that the language is already past its “complexity budget” and that core pain points such as build tooling, modules, and package management remain unresolved. A recurring theme is envy of ecosystems like Rust’s Cargo, with complaints that C++’s fragmented build systems and lack of a standard package format make the language unappealing to new developers despite its dominance in high‑performance domains. Others question whether features like contracts and modules have been designed in a way that will ever see broad, practical adoption, especially given the challenges of compiler support, ABI stability, and C++’s legacy of undefined behavior.

C++ Modules, Builds, and Packaging

  • Many see modules as conceptually good but practically failed so far: tiny real‑world adoption, poor cross‑compiler interoperability, and heavy tooling complexity.
  • Some report good experiences in greenfield projects, but others argue that’s unrepresentative of large, multi‑toolchain codebases.
  • Major blockers: no common binary/module format, incompatible compiler versions/flags, and fragile build graph management.
  • Strong demand for a “Cargo‑like” standard solution: unified build conventions, dependency management, and a blessed package format/registry.
  • Existing tools (CMake, Meson, Bazel, vcpkg, Conan, CPM, WrapDB) are seen as partial, fragmented, or still too complex; opinions differ on which are usable.
  • There’s skepticism that a standard build system or package manager will ever be agreed on, but many argue that lack of one is a key reason newcomers avoid C++.

Contracts

  • Contracts are viewed by some as a crucial step toward stronger correctness and static analysis, enabling specifications of pre/postconditions that tools can exploit.
  • Others argue the design is over‑complex, under‑specified, or misaligned with formal‑verification use cases (e.g., Ada/SPARK style).
  • Concerns: compiler flags that radically change runtime behavior, ODR/ABI issues across translation units with different contract modes, and potential long‑term lock‑in to a “minimum viable” but hard‑to‑evolve design.
  • Some feel contracts merely standardize patterns already implemented with asserts; others see that standardization as exactly the value.

Reflection and Metaprogramming

  • Reflection support is widely welcomed, especially for generating serialization, debug code, and enum/string handling that were previously awkward or tool‑driven.
  • GCC has early support; Clang is behind but experimental branches exist. Implementation complexity and timelines are a concern.

Undefined / Indeterminate Values

  • The new “erroneous behavior” model for reading uninitialized variables is noted as a big semantic change: less catastrophic than classic UB but with some runtime cost.
  • An attribute to opt back into old UB behavior is controversial: clearer to compilers and sanitizers, but adds yet another subtle annotation to learn and reason about.

Unicode and Other Gaps

  • Some criticize C++ for still not handling Unicode in a coherent, end‑to‑end way (e.g., UTF types exist but don’t integrate with regex and other facilities).
  • Others highlight missing or delayed low‑level features (e.g., stable ABI rethinks, restrict, _BitInt) and question prioritization.

Language Complexity and Future

  • Many feel C++ has exceeded any reasonable “complexity budget,” yet the standard continues to add large features (modules, ranges, coroutines, contracts, reflection).
  • There is tension between those who want C++ to freeze and those who argue it must keep evolving to stay relevant to high‑performance and safety‑critical domains.
  • Some suggest newer languages (Rust, Zig, Go, D, Ada, Carbon, etc.) are better fits, but others note C++’s entrenched ecosystem and unique capabilities, especially in HPC, games, GPU, and low‑level systems.