C++26 Disapproved

Original Article ↗ Hacker News Discussion ↗

C++26’s draft international standard has been rejected by ISO national bodies, largely over a controversial “contracts” feature intended to add pre/post-condition checks to the language. Commenters argue this exposes deeper problems: growing language complexity, unresolved memory-safety goals, and a standards process seen as both overly political and resistant to change. Many see the setback as an opportunity either to simplify C++ and focus on safety and tooling, or as further evidence that newer systems languages like Rust will increasingly displace C++ in greenfield projects.

C++26 DIS Failure & Process

  • Draft C++26 (DIS) was rejected at the ISO National Body (NB) level, primarily over the Contracts feature.
  • Some say the NB vote is usually a rubber stamp over WG21’s consensus and see this as breaking a trust‑based norm; others reply that using a formally available veto is legitimate and shows the process working.
  • There is disagreement over whether WG21 actually had “consensus” on Contracts; critics cite ISO’s definition (no sustained opposition) and point to long‑standing objections.

Contracts: What They Are and Why Controversial

  • Contracts are described as structured pre/postconditions and assertions, intended mainly as runtime checks with possible future static‑analysis benefits.
  • Supporters see them as modernizing assertions, helping harden the standard library, aiding tools, and standardizing patterns already used informally.
  • Critics argue the design is complex, poorly specified, and “mostly syntactic sugar” over existing assertion frameworks, with tricky semantics (e.g., observable mode causing UB inside contract checks, ABI and binary‑library issues, exception behavior).
  • Some lament that the original vision (strong static analysis, SAL‑like annotations) was watered down to a minimal runtime feature.

Safety, Profiles, and Language Direction

  • Many comments want C++ to prioritize memory and type safety (e.g., “profiles” or an Ada/SPARK‑like safe subset) rather than adding half‑baked features.
  • Others note C++’s diverse constituencies (legacy vs greenfield, low‑level vs high‑level) make safety work contentious and slow.
  • Some fear Contracts will ossify a weak assertion model and block better designs later.

Complexity, Feature Creep, and Alternatives

  • Widespread concern that C++ is buckling under accumulated complexity; several call for a pause or slower feature cadence.
  • Examples of problematic or stagnant areas: std::regex performance, char8_t, filesystem, ranges, modules, coroutines.
  • Debate over whether NBs should more often veto features to force higher quality.

Ecosystem, Other Languages, and AI

  • Thread discusses Rust’s growth, safety guarantees, and suitability for AI‑generated code, versus C++’s massive existing codebase, ecosystems, and ABI constraints.
  • Opinions diverge on whether AI accelerates C++’s decline or simply changes how C++ code is written and verified.