LDM Notes for September 24th, 2025

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-09-24.md

Agenda

• Union Syntax Thunderdome Part 1

I'm sure no one has opinions on this.

[pinkfloydx33]

If "type-based enums" inherited from System.Enum, could that have the potential to break existing code with generics constrained to enums? Not that I ever really use that feature, but it was the first thing to pop into my head when I read that.

[333fred]

Yes, that would be one of the major problems. It would also likely break large swaths of reflection-based code as well, particularly in serializers/deserializers.

[jnm2]

And tooling that works with ecma335 binaries, including tooling I've written

[sator-imaging]

I'd dive into Union/ADT types in the past. the only problem is that IDE doesn't provide support at all (type-safety works).

and finally I'd realize that there is no benefits in almost cases, IMO.

using System;

public class Program
{
	public abstract class MyUnion
	{
		public sealed class Left : MyUnion { public int Some; }
		public sealed class Right : MyUnion { public Exception Error; }
	}
	
	public static void Main()
	{
		Test(new MyUnion.Left() { Some = 310 });
		Test(new MyUnion.Right() { Error = new Exception("From MyUnion.Right") });
	}

	public static void Test(MyUnion union)  // takes MyUnion
	{
		switch (union)
		{
			// need to maintain the switch cases manually
			// (no error even if it doesn't cover all possible types)
			case MyUnion.Left left:
				Console.WriteLine(left.Some);
				break;

			case MyUnion.Right right:
				Console.WriteLine(right.Error);
				break;

			case int p:  // type-safety works
				Console.WriteLine(p);
				break;
		}
	}
}

[laicasaane]

whether an enum is number-based or type-based

Could we perhaps use a modifier like enum class or enum struct to convey this difference?

In the case enum is number-based, does it mean it only accepts a single number, or also custom type? If a single number then how can enum struct convey that meaning?

How would such enums interact with System.Enum? Would we change the runtime to allow them to inherit from System.Enum? Would that be too large of a breaking change?

Can System.Enum be a special case for union so it can operate the same way as before, with some "union-y" enhancements?

[TahirAhmadov]

I think enum class and enum struct are just fine - distinguished enough from just enum to clearly communicate that it has nothing to do with regular enums and Enum base class. I don't think Enum class should have anything at all to do with these unions (regardless of syntax/keywords chosen).

Another option: union class and union struct can be used to say that it'll define its own cases.

I think homogeneous is fine; if you need to mix and match, you can just define your own options as records and use the plain union syntax. And there is the backstop of just rolling a completely custom type which implements IUnion, so it's not the end of the world.

[orthoxerox]

One key insight is that the union of newly created types is just sugar over the union of pre-existing types; we can likely formalize the former as literally desugaring into the latter, with the new types declared as nested types within the union.

Isn't the reverse also true? A union of pre-existing types is just sugar over the union of newly created transparent wrapper types, which don't even have to be types (and can't be types if it's a struct union). And you can't make a struct union of non-types out of a union of pre-existing types.