# C# Language Design Meeting for September 10th, 2025

## Agenda

- [Unions overview](#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.
