What's new in C++26 (part 1)

Original Article ↗ Hacker News Discussion ↗

New C++26 Features & Ergonomics

  • Many commenters like the “placeholder variable” (_) idea, comparing it to patterns in other languages for ignoring tuple elements; seen as small but ergonomic.
  • Specifying reasons for = delete and user-generated static_assert messages are welcomed for clearer diagnostics and even playful uses (e.g., “games” in compiler errors).
  • Some confusion and clarification about how if (auto [to, ec] = std::to_chars(...)) works: the condition is the returned object’s operator bool, not the individual structured-binding names.

Reflection & Metaprogramming

  • Static reflection (not covered in the linked article but discussed) is viewed as a “game changer” for auto-generating boilerplate like serialization/printing.
  • Others caution that reflection isn’t fully baked yet and could suffer the fate of contracts in C++20 if implementations lag.

Standard Adoption & Portability

  • Strong disagreement on how “usable” newer standards are:
    • Some say C++17 is the latest realistically portable baseline; C++20 still problematic across compilers and platforms, especially embedded / safety-critical.
    • Others report using C++20 or “latest” widely in practice and point to major projects already using C++17/20 features.
  • Concern that each new standard takes longer to implement, potentially leading to a widening gap between spec and real-world availability.

Complexity, Design, and Governance

  • Frequent complaints that C++ is a “monster”/kitchen sink: too many features, hard-to-understand error messages, and growing compiler complexity.
  • Defenders argue:
    • Most additions address long-standing pain points, especially for library authors.
    • Backward compatibility and multi-paradigm goals make some “weirdness” inevitable.
  • Skepticism about standardizing large domain-specific libraries (networking, graphics, filesystem, SIMD); some want the standard to stick to core, generic facilities.

Modules, Concepts, Coroutines, span

  • Modules: some call them effectively DOA for widespread use, citing toolchain/build-system pain and limited visible adoption; others say they work fine in specific toolchains but concede rollout is slow.
  • Concepts are broadly praised and considered mature; coroutines viewed by some as powerful but overly complex.
  • std::span sparked debate: one side calls it a “trap” without default bounds-checking, preferring GSL; others argue this is no worse than other standard containers and should be enforced via compiler options.

Ecosystem, Alternatives, and Migration

  • Many note that large C++ codebases cannot practically migrate to Rust or Carbon; training, tooling, and library ecosystem lock-in are major barriers.
  • Rust and experimental efforts like Carbon and cppfront are acknowledged as interesting, but are framed more as experiments or future possibilities than realistic near-term replacements.