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

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.