C# Language Design Meeting for September 10th, 2025

Agenda

• Unions overview

Quote of the Day

• "I will say 'case' 100 times where no pun is intended, except this one time, where it was intended."

Discussion

Unions overview

Champion issue: https://github.com/dotnet/csharplang/issues/9662
Specification:

• https://github.com/dotnet/csharplang/blob/dab5b33a0b41a95cdc0a8a7b9c5bd33d60eb224b/proposals/unions.md
• https://github.com/dotnet/csharplang/blob/dab5b33a0b41a95cdc0a8a7b9c5bd33d60eb224b/meetings/working-groups/discriminated-unions/union-proposals-overview.md

Today, we took time for a broad overview of the various union proposals being considered for C#, as compiler team members are about to start implementation. We need general agreement on the direction and scope of what is being proposed, using the overview linked above and the proposals linked from it. What follows are the points brought up during discussion:

• Union interfaces are still a debated topic, including:
  • Do we need them at all, or should we wait for concrete use cases?
  • If we don't add them in the first ship cycle, can we ever add them later?
  • Do we need both IUnion and IUnion<TUnion>? We don't have both IAsyncEnumerable and IAsyncEnumerable<T>; only the generic version exists.
  • We need to revisit these questions during the first ship cycle, but we'll keep the interfaces as defined for now to avoid blocking compiler work.
• The specification likely can't claim that a struct union with a single field of a reference type is set/read atomically. C# and ECMA-335 do not guarantee this for non-primitive types, and regardless of whether current implementation realities make it effectively true, nothing stops a compliant runtime implementation from adding padding or otherwise changing the layout of a struct to make reads and writes non-atomic. We may need helpers to ensure this atomicity.
• Union conversions need more detail, such as whether they are standard conversions and where they participate.
• Union constructors and their assumptions around well-formedness may need another look: would it be simpler for users and type authors if they received errors instead of the compiler presuming that, given multiple constructors, any will work?
• There are still general syntax questions; we expect to have full proposals to compare and contrast soon.
• We may want to start more restrictively regarding user-defined versions of generated properties. It's better to start stricter and loosen later rather than the other way around.

Conclusion

We have a strong opening proposal to start implementation. There are still plenty of decisions to make, but we are confident we can proceed and start getting this into people's hands for feedback.