LDM Notes for May 18th, 2026

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-05-18.md

Agenda

• Closed hierarchies open questions
  • Exhaustiveness when no subtypes exist
  • Matching the base type after all subtypes
  • Type parameters constrained to closed types
  • Constraint-based ruling out of generic subtypes

[GeeLaw]

For some reason the team has ignored the question about pattern-matching closed-type argument against interfaces (and its interaction with accessibility). Is it the case that closed-type pattern-matching is intended to not interact in any interesting way with interfaces?

[333fred]

either the compiler must require all direct descendants to be visible to another assembly,

No, this is not the correct conclusion. The only necessary piece is that an inaccessible type is visible to another assembly. There is no requirement that it must implement all the things the real one implements, or that there must be exactly as many cases as are in the source. For example, for structs with private fields, you don't need to include all fields. You only need to keep one dummy field to satisfy definite assignment.

I have no idea whether the benefit is "real" because I have no data.

Then I'd say lets leave theoretical concerns to theory until we have an actual use case.

[GeeLaw]

No, this is not the correct conclusion.

You appear to have miscited. The first option is to ensure that there will be no accessibility issues (prevent less accessible descendants, contrary to what the current proposal intends). The second option is over-generalizing for discovery of non-exhaustiveness. Thanks for pointing this out. To add to it, it’s also beneficial to convert >1 to 1, so that newly added inaccessible direct descendants do not by itself change the reference assembly (better chance of non-recompilation of dependent assemblies).

[RikkiGibson]

My impression about making the subtypes inaccessible, but allowing the caller to exhaust the switch by noticing details about the inaccessible items, is: this seems like an antipattern. Compile-time behavior of a public API, should avoid depending on the shape of internal APIs, including the set of interfaces implemented by inaccessible subtypes.

We already handle an inaccessible subtype scenario, by requiring user to match the base type directly. I think that is good enough. If the author makes the subtypes accessible instead, then there's no motivating scenario for this.

When we do closed interfaces, then we will enrich the exhaustiveness check when interface types are being matched in certain scenarios. Some of these might involve a class being used as the input type of a pattern. But, I don't think allowing an API author to make a closed subtype inaccessible, is a motivation to do additional work for the exhaustiveness check now.

[GeeLaw]

I have no idea why the question/issue should be considered with closed interfaces, other than the fact that its description has both "closed" and "interfaces" as words. Closed interface means I => D1 or D2 or .... Closed classes with all direct descendants implementing I means (B => D1 or D2 or ...) \wedge (D1 => I) \wedge (D2 => I) \wedge ..., which of course implies B => I. They're converse of each other and there's no definite relation between the two.

[RikkiGibson]

I wasn't intending to say there's a direct relation. More that working on "closed interfaces" feature might prompt us to more deeply investigate pattern matching of interfaces in general, and as a result prompt us to make a change that modifies behavior of the scenario you described.

I took a closer look at the scenario in #10190 (reply in thread). The implementation shipping in .NET 11 preview 5 will compile the switch expression without warnings. This is because matching an interface matches all the types that implement the interface.

The behavior seems reasonable. I think people probably shouldn't design closed hierarchies with this behavior in mind, FWIW.

I think if someone trimmed out information about which interfaces an inaccessible subtype is implementing, then, it could cause some switch expression in the consuming assembly to go from exhaustive to non-exhaustive. That also seems fine.

Similarly, a closed hierarchy in which all "leaf types" implement a certain interface, can be exhausted by matching the interface. re: conversion from such a closed type to the interface type--I'll follow up in the thread in here which is directly related to that.

[GeeLaw]

The question about implicit conversion from closed base to an interface implemented by all direct descendants, is related in spirit to the following question:

public closed class B { }
public class D : B { }

B b = GetB();
D d = b;
// Should there be an implicit reference conversion, since all B's are D?

Given that the team has already made some effort in disabling certain conversions from the knowledge about a complete set of direct descendants, enabling certain conversions is in scope.

[GeeLaw]

Regarding the notes:

Type parameters constrained to closed types
...
We will support closed-hierarchy exhaustiveness for type parameters whose effective base type is a closed type. The behavior should match the behavior for switching directly on the closed type, including the corresponding unreachable arm diagnostics.

What's in the proposal.md is the opposite of the resolution. It appears the proposal hasn't been fully updated for this meeting after a week. Just a reminder. Edit: The proposal MD file has been updated.

[GeeLaw]

Regarding 0 subtypes case. The meeting notes say

an empty switch reports a warning, and users can satisfy exhaustiveness by matching the base type itself.

This is bad suggestion. If the type is being authored, it's likely the switch expression should be revisited when the subtypes are eventually added. If the user suppresses the warning by putting an arm to the base itself, there'd be no reminder after adding subtypes.

The implementation already treats this case as non-exhaustive

I agree there should be a warning but the warning should not be "non-exhaustive". As the note already explains, it can assume the code involving non-null B as unreachable. But alas, practicality calls for another suggested solution:

When B is closed and has 0 subtypes, any non-null B is treated as B?. In this solution, temporary code can be written in a way that causes warnings/errors exactly when a subtype is added.

In more details:

• An empty switch is not exhaustive (warning) and can be made so by matching null.
• For a method returning non-null B, in the meeting's solution, it must throw or return null!;, neither reminds the user to revisit code after authoring subtypes. In the suggested solution, it can return null;.
• Once a subtype is added, non-null B is no longer B?. If the user suppressed warnings/errors by matching/returning null (that's intended), there will be warnings/errors reminding the user to revisit code.

Of course, in the suggested solution, switch can still be made exhaustive by matching B, but that's on the users shooting themselves in the foot.

[Richiban]

I'm inclined to agree, for the very reason stated in the notes:

A closed type with no subtypes is likely to be an intermediate state while the author is still writing the hierarchy

Given that a closed type with no subtypes is a legal-but-not-exactly-valid state, we should not be encouraging developers to "handle" it in their switch statements. Giving a warning on the switch will encourage the user (and perhaps a code fix will even exist) to insert the base type into the switch, in which case they've broken the expected guarantees around closed types when a case class is added later.

a switch over an input of that type strongly suggests that the programmer expects an instance to be possible

But an instance of that type is not possible, right? Unless I'm misremembering, closed types are abstract. So, given

closed class C;

void M(C c)
{
    switch (c)
    {
        case C c2: 
            // ... I'd expect an "unreachable code" effect here
            break;
    }
}