# C# Language Design Meeting for August 20th, 2025

## Agenda

- [Discussion](#discussion)
    - [Union interfaces](#union-interfaces)
    - [Target-type inference improvements](#target-type-inference-improvements)

## Quote of the Day

- "So essentially, we have 1007 votes for"

## Discussion

### Union interfaces

Champion issue: https://github.com/dotnet/csharplang/issues/9566  
Unions overview: https://github.com/dotnet/csharplang/blob/c3325533e57dec6aec3266e066e39abf7260e87a/meetings/working-groups/discriminated-unions/union-proposals-overview.md  
Specification: https://github.com/dotnet/csharplang/blob/c3325533e57dec6aec3266e066e39abf7260e87a/proposals/union-interfaces.md

We started today by looking at a proposal for a set of interfaces that would allow existing union-like types to be considered unions by the
language. This proposal is somewhat complicated, and after some discussion, we're not sure that the problem of adapting existing union-like types
needs to be part of the initial set of union features we ship. We have some concerns about whether this will be confusing for new union types to
implement, as these interfaces would be preferred even when explicitly implemented on a type, and we're not convinced that these interfaces would
only be used by older types. Given this, we want to keep this in our back pocket for now and wait to see user scenarios and explicitly design
around them, rather than trying to solve it now.

#### Conclusion

Tabled for now; we will pick this back up with explicit scenarios in mind.

### Target-type inference improvements

Champion issues:
* https://github.com/dotnet/csharplang/issues/9626
* https://github.com/dotnet/csharplang/issues/9627

Specifications:
* https://github.com/dotnet/csharplang/blob/c3325533e57dec6aec3266e066e39abf7260e87a/proposals/target-typed-generic-type-inference.md
* https://github.com/dotnet/csharplang/blob/c3325533e57dec6aec3266e066e39abf7260e87a/proposals/inference-for-constructor-calls.md

Next and last, we looked at proposals for type inference improvements. These affect two main scenarios:
* When calling generic members and providing a target type, and
* When calling the constructor of a generic type.

While these scenarios are initially motivated by our work in unions, they are by no means only applicable to them. For example, a number of generic
factory methods exist only because generic type inference can be performed from the arguments of methods, but not on constructors. We are in favor
of improvements here, but there will be some difficult compat needles to thread. On the one hand, we want users to be able to apply rules that are
already understood to other locations; methods, for example, can be overloaded on generics today. It would be nice if the same intuition that has
been built up around this scenario could apply to types overloaded on generics in constructor calls. On the other hand, we didn't do this back in
C# 2 because of concerns about breaking changes, and it has been a long time since then. However, we are agreed that we need to do some
investigation and experimentation to find the correct point on the dial for compat, and we do think that these are improvements we would like to
see in C#.

#### Conclusion

Proposals accepted for the working set.
