meetings/2025/LDM-2025-08-20.md
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.
Tabled for now; we will pick this back up with explicit scenarios in mind.
Champion issues:
Specifications:
Next and last, we looked at proposals for type inference improvements. These affect two main scenarios:
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#.
Proposals accepted for the working set.