Enum class improvements for C++17, C++20 and C++23

Original Article ↗ Hacker News Discussion ↗

Sum types, std::variant, and enums

  • Several comments argue that C++ has accumulated partial substitutes (unions, inheritance, dynamic_cast, enum class, std::variant) instead of a first-class, closed sum type / algebraic data type.
  • There is contention over definitions: some equate sum types with tagged unions / variants, others insist the core idea is from type theory and not just an implementation.
  • std::variant is criticized as a thin, leaky wrapper over tagged unions: awkward visitors, no reference alternatives, performance overhead, and lack of “automatic” construction like in ML/Rust ADTs.
  • Others reply that limitations (e.g., no T& alternatives) are deliberate design choices and that variant is still useful, but weaker than “proper” sum types in languages like Rust or OCaml.

Pattern matching and future C++

  • Expectation that C++ will gain some form of pattern matching (likely post‑C++26), with multiple competing proposals and even more recent syntaxes.
  • Some predict that once pattern matching exists, pressure will increase for a real language-level sum type because current constructs will feel awkward.

Enum safety, invalid values, and zero-cost abstractions

  • Strong criticism that enum class still allows values outside the declared set, undermining “type safety” and “parse, don’t validate” approaches.
  • Some describe historical reasons: preserving bitmask use, memory-mapped / serialized data, and zero-cost conversion from underlying integers.
  • Alternatives suggested:
    • Exhaustive, closed enums with checked conversion (e.g., returning std::optional).
    • Distinct “safe enum” layers or bitset types instead of abusing enums.
    • An “unsafe”-style escape hatch for bypassing checks in rare cases.
  • Others defend the current design as a pragmatic compromise; stricter semantics would require runtime checks or introduce undefined behavior.

Expressiveness vs explicitness

  • Debate over std::to_underlying vs explicit static_cast to an integer type.
  • One side values generic expressiveness and avoiding repeated type names; the other prioritizes human clarity and explicit target types.
  • Broader discussion contrasts “expressiveness” (what the language can encode) with “explicitness” / readability for humans.

Serialization, reflection, and tooling

  • Multiple libraries are mentioned for Serde-like behavior: JSON serializers, reflection-based approaches (Boost Describe/PFR, Glaze, Boost Hana/Fusion).
  • Reflection in a future standard (possibly C++26) is seen by some as a major enabler for better, more universal serialization and schema export.
  • There is interest in mapping enums and structs to JSON Schema, JSON-LD, RDF/Linked Data, and SHACL, but this is currently library- and framework-specific.

Ergonomics and syntax preferences

  • Mixed views on using enum:
    • Some like shorter syntax and local imports inside functions.
    • Others see it as scope pollution and prefer explicit qualification.
  • Comparisons with Swift/Zig shorthand (.Variant) show a split between those who favor concise, type-inferred enum usage and those who prefer fully qualified names for clarity in larger systems.
  • A few comments express broader fatigue with modern C++’s complexity and footguns, despite incremental improvements like scoped enums and upcoming reflection.