Official proposal for Type Unions in C#

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Many are excited; sum types / discriminated unions are seen as a “once you have them, you miss them everywhere” feature.
  • Some are wary of C#’s growing complexity and “feature bloat,” preferring a cleaner OO story or F# itself.
  • Several note this has been a long‑standing top request for C#.

Why people want union / sum types

  • Strong desire for ADTs / discriminated unions, mainly for:
    • Domain modeling (e.g., Result/Option types, protocol/AST representations like JSON trees).
    • Exhaustive pattern matching that lets the compiler drive refactors and error‑handling.
  • Many compare to F#, Rust, Scala, Haskell, Kotlin, TypeScript, Dart; say it’s hard to go back to languages without ADTs.
  • Some argue ADTs solve the “expression problem” better for codebases you fully own, where recompiling on domain changes is fine.

Current C# workarounds

  • Use of sealed record hierarchies with private constructors to emulate closed unions + switch pattern matching.
  • Libraries such as OneOf, language-ext, and DU/code‑generator packages.
  • Visitor pattern for exhaustiveness in OO style.
  • These lack first‑class exhaustiveness checking and are seen as verbose or fragile.

Design details, safety, and performance

  • Discussion of CLR rules: overlapping object references and value fields via explicit layout is illegal; runtime throws TypeLoadException.
  • Concern about union structs overlapping reference and value fields and about tearing under concurrent modification.
  • Some suggest union structs may need to store fields side‑by‑side (more space, safer semantics).
  • Questions about whether Roslyn/runtime will optimize layouts when aliasing is allowed among value‑only fields.
  • Clarification that planned “union structs” are logically tagged unions even if syntax sometimes looks like ad‑hoc unions.

Terminology and syntax debates

  • Debate over naming: “type unions” vs established terms like “sum types” or “discriminated unions.”
  • Confusion because proposal includes both closed sum types and “ad hoc unions” (TypeScript‑style), which behave differently.
  • Some dislike proposed syntax and worry C# is drifting into an “uglier F#,” or duplicating concepts (records, tuples, unions).

Comparisons to other ecosystems

  • F#: praised for ADTs and ergonomics; concerns it’s treated as second‑class and that C# slowly cannibalizes its advantages.
  • Java/Kotlin: Java now has records, sealed classes, and pattern matching; Kotlin sealed classes are cited as very similar.
  • Rust: unions/ADTs and derive macros are a big draw; some choose Rust over C# mainly for this.
  • Dart: already has sum types + pattern matching; union types proper are described as harder and of unclear value.

Timeline and maturity expectations

  • Proposal is early: status fields marked “not started.”
  • People estimate at least ~2–3 years before it appears in a released C#, not in the imminent .NET release.