C++26: A Placeholder with No Name

Original Article ↗ Hacker News Discussion ↗

Use of _ as a discard / placeholder

  • Several compare C++26’s unnamed placeholder to existing “discard” conventions:
    • C#: _ signals an intentionally ignored value, including multiple independent _s in tuple destructuring.
    • Prolog had _ as an anonymous variable in the 1970s; some speculate this pattern predates computing as a general “redaction” symbol.
  • Rust is discussed as a contrast:
    • Binding to _ in Rust immediately drops the value; it can’t be used to keep a lock or RAII guard alive for a scope.
    • Some argue this decision may be regretted long-term, though Rust otherwise doesn’t have the motivating C++ problems (rebinding, unused-variable warnings) in the same way.

C++ complexity, legacy, and Rust/C comparisons

  • Some see the proposal as yet another sign of C++’s “convoluted mess”; others say this particular change actually simplifies code.
  • Debate on whether Rust will replace C++:
    • One side: Rust (or its successor) will gradually displace C++; C++ may end up like COBOL, mostly legacy but still around.
    • Other side: C++’s installed base (including compilers) is vastly larger than COBOL’s; it will persist for decades.
  • Comparisons of safety:
    • Pro‑C++: RAII, destructors, smart pointers, and stronger typing make it safer than C.
    • Skeptics: C++ just moves many hazards into the standard library (iterator invalidation, dangling string_views, UB); debugging can be harder than in C.
    • Rust is seen as safer but also accumulating complexity; some criticize its ergonomics, especially borrow checking, lifetimes, and heavy use of Option/Result “breadcrumb” chaining.
    • C is argued to remain relevant, especially as a universal ABI layer.

auto and type inference

  • Large subthread on auto:
    • Critics: harms readability, especially when learning a new codebase or reading in a browser/code review without IDE help.
    • Supporters: reduces redundancy and refactoring pain; vital for long template types, lambdas, iterators, and coroutine types.
    • Common compromise: use auto when the type is obvious or irrelevant locally; spell out types at API boundaries and where it aids understanding.
  • Strong disagreement over relying on IDEs/LSP:
    • One camp: not using an IDE is “doing it wrong”; modern tooling makes inferred types trivial to inspect.
    • Other camp: code should remain understandable without “fancy” tools; greppability and explicit types are part of good API and library design.

Meta

  • Some argue not every annoyance in C++ needs a language feature.
  • Others see these incremental changes, including placeholders and auto, as necessary to keep C++ usable despite its accumulated complexity.