LDM notes for June 25th, 2025

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-06-25.md

Agenda

• Unions
  • Stand-alone issues
  • Mutually exclusive issues

[xparadoxical]

Is there a reason anonymous syntax couldn't be supported with nominal unions? Basically, for a declaration of an (int or string) prop/field/local/return, the compiler could generate a special nominal union and enforce usual union rules for it. There'd be at most one declaration of an (int or string) type in an assembly. Something like (int or string) u = IntOrString(); wouldn't require a new type to be generated, as there's already one to be used, generated by the declaration of IntOrString. void M((int or string) u) would require a generated type and M(u) would convert u to the generated type if it's a different one.

[HaloFour]

I think forcing the type to be named avoids many of those problems that comes with an anonymous declaration, such as generating a stable name or sharing across assemblies. I think it also helps to ensure that people don't get the idea that these are not actually type unions as far as the runtime is concerned. You can't box IntOrString and unbox as either an int or a string, nor to a StringOrInt. They are all separate and incompatible types.

[Richiban]

Is there a reason anonymous syntax couldn't be supported with nominal unions

Well, if nothing else, "anonymous" and "nominal" are opposites :P

[xparadoxical]

Well, if nothing else, "anonymous" and "nominal" are opposites :P

"Compiler-only" then 🙄

[jnm2]

If you're not declaring a name, then the idea of being aware of an intermediate wrapper, that you sometimes have to unbox to via explicit cast, is way less appealing. We're leaning into this idea that the wrapper is not transparent.

In other words, a name shows that there is a wrapper which enforces the invariant (this is one of case A, case B, etc).

A lack of name would communicate an expectation that this is just a reference with no wrapper: this is an "int or string," directly. And here we need potentially to wait years for deep runtime support, and even then it may never support the illusion 100%. For instance, how would you avoid boxing if there is no wrapper? Either you accept boxing, or that would be even more deep runtime work.

Runtime work means delaying the feature as well as giving up other runtime features whose time was taken by anonymous unions.

[mattwar]

The nominal type union proposal itself has no support for anonymous type unions, since it is a named typed union. However, that doesn't mean there cannot still be anonymous type unions in the language. It will have to be a separate proposal though. The way that runtime type unions work, however, implies that there are anonymous type unions so a syntax for it is included as part of that proposal, but we are not moving forward on that one.

[Richiban]

closed enums, closed hierarchies, and case classes [...] We strongly believe that these should be a priority for the LDM in the near term.

Honestly, such happy days! 😄

[MgSam]

How do closed enums work if you cast to object?

closed enum Dog { Rover = 1, Lassie }
var d = (Dog)(object)3; //Presumably this compiles - will it fail at runtime?

I'm assuming there is no runtime validation? The proposal does not make that clear.

[CyrusNajmabadi]

If you want to be forced to handle this case, just use a normal enum. The idea of making a closed enum is you are stating that this could only happen by code subverting the system, and that's not the domain of cases you think you need to care about.

It's the same thing as doing a .Length check on a string, only to find that that length changed out from under you due to unsafe code. Sure, that's possible, but having to have all your code actually be written to validate that is just onerous.

Note that the compielr will already emit the default case which will throw, indicating the something invalid did enter the system.

[RikkiGibson]

anytime you read data from some external source (json, database, etc).

I imagine that when the feature goes out, over time, tools which care about respecting the closed-ness of enums will validate the values being translated to the closed enum type. We saw similar things happen with non-nullable reference types, where System.Text.Json has the ability to verify nullability when deserializing, analogous work in EF Core, etc.

[MgSam]

If you want to be forced to handle this case, just use a normal enum. The idea of making a closed enum is you are stating that this could only happen by code subverting the system, and that's not the domain of cases you think you need to care about.

It's the same thing as doing a .Length check on a string, only to find that that length changed out from under you due to unsafe code. Sure, that's possible, but having to have all your code actually be written to validate that is just onerous.

Note that the compielr will already emit the default case which will throw, indicating the something invalid did enter the system.

I'm not talking about unsafe code. A web server receiving serialized JSON is not "something subverting the system". In fact, web servers are the primary use case for which C# is designed and used these days. If a property is typed as an enum and the json contains an invalid value from some random client, I shouldn't have to manually remember to code validations because the language feature is insufficient to handle the use case. I also shouldn't have to rely on individual serializer libraries coding validations (which let's be honest- will never happen for most database libraries)

Make invalid optional - unless I'm missing something it seems like a trivial feature to add while providing a ton more safety than these "compile time only" features you guys keep adding.

[CyrusNajmabadi]

I'm not talking about unsafe code. A web server receiving serialized JSON is not "something subverting the system"

That case is suppsoed with closed enums. You receive the json and map the values to the supported cases. If the server gives you a value you don't understand, you can't map it.

I shouldn't have to manually remember to code validations

I don't know what this means. You'll have to process hte json and map the values you get from it to your closed set of enum cases. Because the json is open ended, you'll have to handle the case of something you weren't expecting.

[mattwar]

Things like Enum.TryParse will still work. Unboxing an enum from object should still work. Reflection will still work. However, converting a number to an enum without being it statically proven to match a declared value will not work.

[Mrxx99]

Is this thread safe?

public sealed record Closed : GateState { 
    public static Closed Instance => field ??= new Closed();
}

[HaloFour]

I expect the code described is only illustrative of the expected singleton behavior and not representative of the actual IL that will be emitted.

[jnm2]

Yes, this provides full thread safety, and aren't there cases where this is already what the compiler emits?

public sealed record Closed : GateState { 
    public static Closed Instance => LazyInitializer.EnsureInitialized(ref field);
}

[HaloFour]

Yes, this provides full thread safety

Nit, that method is effectively LazyThreadSafetyMode.PublicationOnly, so it is possible that the constructor may be invoked more than once but you are guaranteed that only a single instance will ever be returned.

[jnm2]

For a DU singleton case, I can't imagine it could hurt to run the ctor more than once.

[mattwar]

The proposal only showing a possible implementation to get the idea across simply.