# C# Language Design Meeting for May 20th, 2026

## Agenda

- [Unions](#unions)
    - [Union pattern matching target for custom unions](#union-pattern-matching-target-for-custom-unions)
    - [Missing required APIs in custom union declarations](#missing-required-apis-in-custom-union-declarations)
    - [Direct value property matching and union rules](#direct-value-property-matching-and-union-rules)

## Quote of the Day

- "Can we make it so that `is 10` does an `int.Parse` if you have a `string`? Or a `Convert.ToInt32`? And make it locale dependent?"

## Discussion

### Unions

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

#### Union pattern matching target for custom unions

Spec: https://github.com/dotnet/csharplang/blob/672991dbc4479efdb51669c5bd242cefaa25ca71/proposals/unions.md#union-matching  
Working group notes: https://github.com/dotnet/csharplang/blob/672991dbc4479efdb51669c5bd242cefaa25ca71/meetings/working-groups/discriminated-unions/union-patterns.md

The working group brought this unions topic to LDM, and we focused on how pattern matching should target custom union
instances. The motivating scenario was an existing union-like type that adopts `UnionAttribute`: once that happens, current
"always match against `Value`" behavior can break existing property patterns that previously matched on members of the
wrapper type itself.

We examined three approaches. The first was to keep current behavior and always target `Value`. The second was a
syntax-based split where patterns with explicit type tests target `Value` and untyped patterns target the outer union
instance. The third was a "try both" model for type-test patterns, where matching tries the union instance first and then
falls back to the `Value` content.

The discussion highlighted a tradeoff between predictability and compatibility. The syntax-based model is easier to teach,
but leaves valid scenarios unsupported. The "try both" model better preserves existing code and often aligns with user
expectations, but introduces more subtle reasoning and implementation complexity. We also discussed whether broader goals
for custom unions should prioritize gradual adoption of existing ecosystem types or strict, simple semantics for new union
code.

We took a read of the room and found broad interest in doing something, but no stable consensus on which direction to choose.
The room had a slight lean toward a syntax-based option, with many uncertain positions remaining.

#### Missing required APIs in custom union declarations

Spec: https://github.com/dotnet/csharplang/blob/672991dbc4479efdb51669c5bd242cefaa25ca71/proposals/unions.md#should-compiler-report-an-error-for-custom-union-declarations-in-source-that-are-missing-the-minimal-set-of-apis

We then reviewed whether source-declared custom unions should be required to contain the minimal API surface, such as at
least one creation member and a valid `Value` member, or whether these should remain advisory and fail only when specific
features are exercised.

The core concern was ensuring fail-fast usability. If the compiler does not validate the minimum union shape up front, users can
end up with delayed failures far from the declaration site. We preferred diagnostics that point directly at the malformed
declaration, so errors appear at the moment the type is declared as a union.

##### Conclusion

The compiler should report errors for custom union declarations in source when the minimal required API set is missing.

#### Direct value property matching and union rules

Spec: https://github.com/dotnet/csharplang/blob/672991dbc4479efdb51669c5bd242cefaa25ca71/proposals/unions.md#should-direct-value-property-matching-follow-union-rules

Finally, we discussed whether direct matching on `u.Value` should apply union knowledge, including union-specific
reachability and exhaustiveness implications, or whether direct `Value` access should behave like ordinary `object`
matching.

We preferred consistency between matching on the union instance and matching on its direct `Value` property. When both
forms lower to the same underlying semantics, users should get aligned diagnostics. This includes recognizing impossible
matches based on known case types and suppressing unnecessary exhaustiveness warnings when all union cases are covered via
`Value` matching.

We compared this to earlier list-pattern discussions where different syntactic forms that lower to equivalent checks are
expected to inform one another for reachability and exhaustiveness, rather than diverging purely because of spelling.

We also noted that users who intentionally want to drop union-aware behavior can still do so by introducing an explicit
`object`-typed intermediate, which provides an escape hatch without weakening default diagnostics.

##### Conclusion

Direct matching on the `Value` property should follow union rules, using union knowledge for diagnostics and analysis.
