LDM Notes for October 1st, 2025

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-10-01.md

Agenda

• Closed enums
• Closed Hierarchies

[TahirAhmadov]

What about exhaustiveness in switch statements; presumably we want it to handle not needing a default case for returning, but how will that interact with switch statements that are intentionally not exhaustive, or in void-returning methods where there isn't a "you forgot to return" error?

Both of those shouldn't change, IMO. The only time a switch should be exhaustive is when control flow dictates it - missing return, or it's a switch expression.

[RikkiGibson]

I think that when a developer uses closed types, it's most likely out of a desire for exhaustiveness to be explicitly considered at use sites. So, I feel that non-exhaustive switch statements over closed types should result in a warning by default.

If you do not want to be prompted to handle new cases for a closed type that are added over time, you should explicitly put a default label in the switch statement. Or, if you don't want the enforcement across the board, put <NoWarn> for it in the project.

closed enum MyEnum { One, Two, Three }

void M(MyEnum e)
{
    switch (e)
    {
        case MyEnum.One: HandleOne(); break;
        case MyEnum.Two: HandleTwo(); break;
    } // warning: switch is non-exhaustive

    switch (e)
    {
        case MyEnum.One: HandleOne(); break;
        case MyEnum.Two: HandleTwo(); break;
        case MyEnum.Three: HandleThree(); break;
    } // ok, and will warn again if a new case is added later.

    switch (e)
    {
        case MyEnum.One: HandleOne(); break;
        case MyEnum.Two: HandleTwo(); break;
        default: HandleDefault(); break;
    } // ok, and will never warn again about new cases.
}

Handling of "nested patterns over closed types", I'm less sure about. Possibly a similar switch over type MyEnumHolder with property MyEnum MyEnum { get; } and cases case { MyEnum: MyEnum.One }: ..., etc. should work similarly in terms of warnings.

[Tinister]

What about #8925 and #8607? So then I can close my enums and then convert all my switch statements. 😊

[sator-imaging]

I expect same manner is applied to closed hierarchies.

interface IMessage {}
class Damage : IMessage {}
class Heal : IMessage {}

static void Receive(IMessage message)
{
    int x = message switch
    {
        Damage => -100,
        Heal => 100,
    };  // raise error if new message type is added
}

And it's nice to have closed interface supported and a choice of assembly protection such as public closed protected class LimitToSameAssembly.
(and auto-fill switch case feature is really welcomed)

[Unknown6656]

I don't see the need for the closed-keyword/[Closed]-attribute, when one can simulate a closed hierarchy using:

public class Animal
{
    private Animal( ... ) { ... }
    
    ....
    
    public class Dog : Animal { ... }
    
    public class Cat : Animal { ... }
}

which would prevent other classes from inheriting from Animal. An analyzer should be able to recognize the pattern of classes with all constructors marked as private and can thus assume that all descendants from that class are members of a closed hierarchy.

One can even use the partial-modifier to spread that hierarchy across multiple files if needed.

[333fred]

closed does not require that inheritors are nested types.

[Unknown6656]

That is true. However, does the constraint of not being able to place inheritors outside the parent class warrant the effort of introducing the 'closed'-keyword?

[HaloFour]

Yes. Many domain models already designed today would be considered closed if there was already a mechanism to do it. Not to mention, closing the hierarchy doesn't prevent inheriting from one of the cases, it only prevents adding another top-level case.