LDM Notes for September 29th, 2025

[333fred]

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

Agenda

• Union Syntax Thunderdome Part 2
• Enums vs Unions

[TahirAhmadov]

How about union Pet { Cat, Dog }?
And enum class/enum struct sounds straightforward.
For string enums, better do enum Foo : string

[333fred]

How about union Pet { Cat, Dog }?

Already ruled out last time.

[TahirAhmadov]

Oh OK, I don't think I saw it in those notes. Out of curiosity, what was the reason for rejecting it?

[333fred]

We ruled out all in-body lists.

[huoyaoyuan]

By the term in-body, is it the goal to leave braces {} for regular member methods, as opposed to enum?

[jnm2]

It means that anything appearing inside the braces is a declaration of a new thing, not a reference to an existing type.

[sator-imaging]

Maybe off focused, but clarify, many developers want the TypeScript's flexibility.

In typescript, declare funciton like this,

function foo(arg: string): void
{
    console.log(arg);
}

ofcourse, foo(0) will cause compile error. then, declare like this,

function foo(arg: string | number): void
{
    console.log(arg);
}

now foo(0) works as arg accepts string or number.

but, this doesn't illustrate TypeScript's flexibility. TypeScript's | operator actually defines "possible values". so, the following crazy example is valid and works as expected.

function foo(arg: "cat" | -1): 100 | "dog"
{
    return arg === "cat" ? 100 : "dog";

    // error
    //return 500;
    //return "animal";
}

if (foo(-1) === 200) {  // error because foo never returns 200 

}

PS. TypeScript has another feature, discriminated union and it's helpful.

[huoyaoyuan]

arg: string | number

I believe many developers dislike this. A particular reason for this to exist is the horrible auto conversion in JavaScript.

TypeScript's | operator actually defines "possible values".

This enters the region of dependent type. TypeScript uses this because JavaScript APIs use string parameter to determine the API surface return type of certain functions. This isn't the case for .NET BCL.

[sator-imaging]

I agree inline union declaration is so horrible. I've experienced it by scattered declarations of ValueTuple in C# but today we have the solution.

global using MyTuple = (bool foo, int bar);

// pseudo declaration for union
global using HttpOk = "OK" | 200;

I welcome to Enum system update and am pointing that it is separate concern from Union. Class based enum may not cover union type usecases.

[HaloFour]

Personally I still have reservations about the use of tuple-like syntax for the union types. Everywhere else you see that in C# today (or in most languages) that defines a product type, not a sum type. Is the union keyword enough to differentiate it in this one case?

I really don't understand how a union would have a primary constructor, though. What would you do with that additional state?

[jnm2]

I agree, state in a type union besides the instance of the unioned type seems suspect.

[jjonescz]

What about union Pet = Cat | Dog | Bird;? Seems clear enough and similar to prior art in other languages. Could also allow leading | for nice formatting like

union Pet =
    | Cat
    | Dog
    | Bird;

If we ever want anonymous unions in the future, we could reuse the X | Y syntax for that.

[viceroypenguin]

Honestly, I think I like this the best. Yes, it's more functional and isn't as natural for C# syntax, but I think it fits better with the intentions for unions.

[DavidArno]

I'm surprised this option wasn't in that large list as well as it is similar to F# and just feels a nice way to express a union. But union Pet(Cat, Dog, Bird) is OK and really I'm way more interested in actually having unions than what colour its bike shed might end up being 😀

[CyrusNajmabadi]

It was rolled into union Pet(Cat | Dog | Bird);

Ultimately, we just didn't feel strongly on it.

[MgSam]

I'd like to add union Pet private protected Cat, Dog, Bird; to the list. :)

[DavidArno]

Could we expand that, please:

union Pet(private protected Cat, sealed Dog, Bird : IFlappy)

[CyrusNajmabadi]

No. our goal with unions is actually to go the other way. They should be exceedingly simple. They're just a bunch fo types. Creation of those types (beyond the numerous ways we already have to do that in the language today) falls into other features (like 'case clauses') or 'enum structs/classes'.

That way there are nice composable features, and 'union syntax' itself doesn't become a grabbag mishmash of features.

[jnm2]

Sam was certainly joking around by referring to the syntax paroxysms around private protected, and I assumed David is playing along with the joke :D

[DavidArno]

Yes, sorry. My comment wasn't meant to be taken seriously. My bad.

[CyrusNajmabadi]

oopsy :D

[Richiban]

We expect this to come after the union feature, building on that as the way that these enums get translated into actual types, but we do expect it to happen.

Do you mind explaining a little more on this point? The two features, while perhaps having some usability overlap, don't seem immediately related so it's not obvious to me why one would be built on the other and they must therefore be developed in series.

[333fred]

We are envisioning that enum classes/union classes/enum unions/whatever we end up calling this is to unions as record classes are to classes.

[Richiban]

Ahh, so "enum classes" are essentially a special case of "unions"? Or vice versa

[333fred]

Correct.