C++ Evolution Proposals: Eras, Realistic Standards, and Revamped Exceptions
C++ developers grapple with three versions of the language: the one described in the standard but unavailable; the experimental one in cutting-edge compilers; and the real one in widely used versions. This gap between theory and practice needs fixing. The proposal: once a feature is approved, move it to a technical specification for compiler implementation. It only enters the full standard after support in at least two major compilers.
This approach uncovers issues during implementation, allows tweaks without standard changes, and ensures features are actually available in compilers when the standard ships. Experimenters get early access to new features right after they land in GCC or Clang.
Eras Mechanism to Ditch Legacy Compatibility
Introducing 'eras' at the top of .cpp files would declare the C++ version for that module. This lets us purge decades of accumulated cruft: automatic numeric type conversions, signed/unsigned comparison pitfalls, implicit array-to-pointer decays, and multiple initialization syntaxes.
Key benefits:
- Mix-and-match files from different eras in one project without rewriting legacy code.
- Transpile modern code to older standards to preserve ABI compatibility.
- Evolve an improved C++ without backward compatibility to C dragging it down.
Eras prevent the language from bloating into a monster under the weight of historical baggage.
Rethinking Exceptions in C++
Exceptions in C++ were a 1980s flop: expensive, unpredictable, and banned in half of all projects. Alternatives like std::expected don't fix reliability issues. We need zero-cost exceptions integrated with eras: new ones only in files from recent eras.
Blending old and new code poses integration headaches, but the status quo is untenable. The community split between 'with exceptions' and 'without' stalls progress.
Key Takeaways
- Standards should codify implemented features, not race ahead via technical specifications.
- Eras enable mixing legacy and modern code while cleansing new code of historical mistakes.
- New zero-cost exceptions roll out by era, cutting overhead and boosting predictability.
- Without these changes, C++ risks PL/I's fate: exploding complexity with no gains.
- The committee should prioritize strategic mechanisms over tactical minutiae.
Conclusion and Outlook
For C++ to thrive another 40 years, it needs bold shifts: pragmatic standards, eras for evolution, and a exceptions reboot. This unifies the ecosystem, simplifies new code, and preserves legacy. The committee must shift from declarations to documenting real-world practice, letting the language adapt without past burdens.
— Editorial Team
No comments yet.