LDM notes for July 30th, 2025

[MadsTorgersen]

https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-07-30.md

Agenda

• '/main' and top-level statements
• Union proposals overview
• Add type parameter restriction to closed hierarchies
• Standard unions
• Union interfaces
• Custom unions
• Non-boxing access pattern

[HaloFour]

I'd love the runtime to weigh in on what kind of effort/time would be required to have runtime support for Union<...> which would support boxing, commutativity, etc. It would be impossible to add such support later without breaking changes, and I find those helper types aren't critical to shipping a feature in this space.

I understand some of the concerns around GVM, but does support for those patterns extend to interfaces and generic constraints so that I could define my own IUnionUnboxed interface or whatever? Would having those interfaces themselves be generic help, e.g.?

// have a couple of these interfaces up to a certain arity
public interface IUnionUnboxed<T1, T2> {
    bool TryGetValue(out T1 value);
    bool TryGetValue(out T2 value);
}

public struct MyUnion : IUnion, IUnionUnboxed<int, DateTime> {
    object? IUnion.Value { get { ... } }

    public bool TryGetValue(out int value) { ... }
    public bool TryGetValue(out DateTime value) { ... }
}

[GabeSchaffer]

I'd love the runtime to weigh in on what kind of effort/time would be required to have runtime support for Union<...> which would support boxing, commutativity, etc

Yes, I too would like to know what the cost would be. I know that the work required to implement runtime support for Nullable<T> delayed .NET 2.0, but 20 years on, the work turned out to be invaluable and I'm guessing nobody even remembers the release was late!

[qrli]

What's the design/decision for the relation between union and nullable? e.g.

• Is Union<string?, int?> allowed?
  • What does u.HasValue mean when case types contain nullable? Is a null string value treated as the string? case or int? case, or no case no value at all?
  • If value null means no case no value, does that mean that a union always implicitly has an extra case which always need to be checked?
• Can a has-no-value union be compared with null?
• Is Union<string?, int?>? allowed?
  • What does u.HasValue mean in this case? The Nullable<>.HasValue or Union<>.HasValue?

[qrli]

@HaloFour If you are right, then it means:

• A union always have an extra null case.
  • While I can understand why, it is less sound than TypeScript/F#'s union, and defeating the purpose of NRT. I'd guess, maybe as part of NRT, there would need to be a non-nullable version of union.
• Nullable case types won't be allowed, or won't have any effect.
  • But I'd doubt about Union<Nullable<int>> - even if C# disallows it, it may still be possible to be constructed using BCL?
• It would be possible to define Union<string?>? unless they decided to disallow it.
  • Which leads to the question: what does u.HasValue mean in this case? The Nullable<>.HasValue or Union<>.HasValue?

[qrli]

One of the proposals is alternate access patterns so the compiler can avoid boxing.

Question is whether Union<...> might be able to employ them or if that will be more for custom union types. If Union<...> has to resort to boxing internally for storage then those patterns don't really help.

My read of the notes is that - using the CLR/BCL union type won't auto utilize the non-boxing methods, but languages/compilers will try to use the non-boxing methods for language-specific syntax sugar.

[HaloFour]

Based on my understanding of the current proposal ...

A union always have an extra null case.

Yes, even if all of the type parameters are value types, assuming that Union<...> is based on internal storage using object. If that's not the case, or the runtime (eventually) does some kind of magic, who knows.

Nullable case types won't be allowed, or won't have any effect.

I expect that they'd be allowed, but that attempting to match on a union containing null would not succeed except when matching for null. In effect it would behave the same way as if you assigned that value to object and then tried to match it.

It would be possible to define Union<string?>? unless they decided to disallow it.

The runtime wouldn't disallow it. I expect that even if the language attempted to disallow it that it would still be trivial to end up in that state through generics, so probably not worth attempting to forbid it.

Which leads to the question: what does u.HasValue mean in this case? The Nullable<>.HasValue or Union<>.HasValue?

u.HasValue would be Union<...>.HasValue (assuming said member exists). I've not seen anything that suggests that the language would attempt to flatten any of the members of the unioned types, you'd have to access it's underlying value via the Value property (or the TryGet helper methods, if they exist).

[qrli]

@HaloFour Regarding my last question, I was asking about Union<string?>? which is Nullable<Union<string?>>

[HaloFour]

Regarding my last question, I was asking about Union<string?>? which is Nullable<Union<string?>>.

Oh, in that case I would expect the following. This is assuming that on launch there will be no special runtime support, and Union<...> types are structs that you or I could declare ourselves today.

// given
string? s = null;
Union<string?, int> u = new Union<string?, int>(s);
Union<string?, int>? nu = u;
object o = nu;

// then
Debug.Assert(u.HasValue == false);   // the value of the union type is null
Debug.Assert(nu.HasValue == true);   // the value of the NVT is the union struct itself
Debug.Assert(o != null);             // the union struct boxed

I'm not aware of any syntax candy for anything except for pattern matching:

if (u is string s) { }

// becomes
if (u.Value is string s) { }
// or
if (u.TryGetValue(out string s)) { }

But that's my assumptions based on what's been proposed so far. I kind of expect the Union<...> types to have a fairly light touch and not attempt to elide the wrapper struct in most circumstances.

[MgSam]

When did LDT adopt the closed enums proposal? Last update we had it was still a proposal.

I still think you guys are making an unforced error in not allowing the switch over closed enums to catch invalid values of the enum.

closed enum Dog { Lassie, Rover, Fido }

var json = "-1";
var myDog = JsonConvert.Deserialize<Dog>(json);  //Illustrative syntax, I know the actual json libraries are slightly different from this

switch (myDog) {
    case Lassie: ...
    case Rover: ...
    case Fido: ...
}

// I now get here with *no* compiler warning, when in fact my code has a serious bug in it. 

This feature is building a new footgun into the language. It is definitely not a pit of success.

[CyrusNajmabadi]

When did LDT adopt the closed enums proposal?

We continue to design and discuss it

I still think you guys are making an unforced error in not allowing the switch over closed enums to catch invalid values of the enum.

A switch over a closed enum will still catch and throw on invalid values of the enum.