[Proposal question]: Should the immediate descendants of a `closed` type be required to have the same accessibility as the base?

[eiriktsarpalis]

• Champion: [Proposal]: Closed Hierarchies (VS 18.8, .NET 11) #9499
• Spec section: Exhaustiveness when a subtype can't be used
• Prior LDM decision (2026-04-20): Accessibility and exhaustiveness
• Related: dotnet/runtime#129041 (STJ support), dotnet/runtime#129009 ([IsClosedType])

The problem

A closed class restricts derivation to its declaring assembly so that a switch over its direct descendants can be treated as exhaustive. Today a direct subtype may be less accessible than the closed base, in which case a consumer that can see the base but not the subtype can never write an exhaustive switch:

// Library assembly
public closed class Shape { }
public sealed class Circle : Shape { }
internal sealed class Hidden : Shape { }   // less accessible than the public base

// Consumer assembly
string Describe(Shape shape) => shape switch
{
    Circle => "circle",
    // warning: switch is non-exhaustive. Pattern 'Shape' is not handled.
    // But 'Hidden' is internal to the library and cannot be named here, so the consumer
    // can never exhaust the switch by matching the derived types.
};

The current proposal accepts this and reports it only at the use site (the spec section linked above). LDM considered a declaration-time accessibility restriction on 2026-04-20 and declined: "We will not add any new restrictions related to accessibility."

The question

Should we revisit that decision and require, at declaration time, that every immediate descendant of a closed type have the same declared accessibility as the base?

Proposed rule

Every immediate descendant (direct subtype) of a closed type must be declared with the same declared accessibility as the closed base type; any other accessibility is a compile-time error.

public closed class Shape { }

public sealed class Circle : Shape { }    // ok: same accessibility as 'Shape'
internal sealed class Hidden : Shape { }  // error: a direct subtype of a closed type must have
                                          // the same accessibility as its base

Considerations in favor

• Exhaustiveness then holds for every consumer that can see the base — which is the point of closed.
• A declaration-time error is actionable at the hierarchy, versus a non-exhaustiveness warning in distant (possibly cross-assembly) consumer code that the consumer cannot fix.
• The direct descendants are part of the type's contract; hiding cases from consumers who can see the base contradicts what closed advertises.
• STJ's closed-hierarchy support (JsonSerializerOptions.InferClosedTypePolymorphism, runtime#129041) infers a $type discriminator (nameof(DerivedType)) for every derived type recorded in [IsClosedType(DerivedTypes = …)] (runtime#129009); permitting less-accessible descendants means an untrusted payload could instantiate an otherwise-inaccessible type/constructor — a potential security concern, which STJ is likely to decline to support regardless.

Scope and related considerations

• file-local closed classes. file is a separate modifier, not a named accessibility level, so it needs explicit treatment: a file closed base should require file-local direct subtypes (and a more-visible base cannot have a file subtype). The current implementation has not exercised file closed class; that gap needs coverage regardless of the outcome here.
• Unspeakable or constraint-adding generic subtypes. The spec's Exhaustiveness when a subtype can't be used already notes that a generic subtype can be unspeakable for a given base instantiation — e.g. class D2<V> : C<V[]> under closed class C<T>, where no D2<…> pattern can be written for an existential C<X>. The same reasoning behind this question applies: guaranteeing a usable construction wherever any base construction is used would mean disallowing such non-speakable derived generics at declaration, effectively restricting generic subtypes to "trivial" generics — ones that pass their type parameters directly to the base and add no constraints of their own. Best treated as a separate question.
• Consumption-site dependency on inaccessible metadata. Reference assemblies and trimming tools would have to special-case descendants of a closed class to keep consumer pattern matching correct, and Roslyn metadata-import modes that hide inaccessible members interact poorly with consumption-site behavior that depends on inaccessible derived types. This is the same class of hole already known from private struct fields (managed/unmanaged determination — and thus pointer eligibility — depending on inaccessible fields); we would prefer not to enlarge it. The rule removes the dependency.
• Nested closed levels. The rule applies to each closed type's own direct descendants independently; deeper hierarchies stay matchable.
• Type parameters constrained to a closed type. Unaffected — that concerns generics and exhaustiveness, not accessibility.

Options

1. Adopt the rule as a compile-time error — strongest guarantee; a closed type is always exhaustively matchable by every consumer that can see it.
2. Adopt the rule as a warning — flags the hazard at declaration without hard-breaking the pattern; weaker guarantee.
3. Status quo (2026-04-20) — no declaration-time restriction; continue reporting non-exhaustiveness only at the use site.

Sub-decision for options 1 and 2: whether the rule extends to require matching file-locality, as described under Scope and related considerations.

[HaloFour]

Was there a situation that arose that is driving wanting to reconsider the design, or is this just a disagreement with that decision?

Will note that Java does allow lower accessibility of implementing types of a sealed/closed hierarchy.

[RikkiGibson]

re: Java. I didn’t realize that. Can you put a type in the ‘permits’ list, which isn’t accessible from the base class otherwise..?

[HaloFour]

re: Java. I didn’t realize that. Can you put a type in the ‘permits’ list, which isn’t accessible from the base class otherwise..?

Yes, as long as it's accessible from the declaration of the sealed type. Consuming code that can't access those types can't be considered exhaustive without a default case or the like.

I don't know what the use cases are for doing this, just noting that Java does allow it.

[MadsTorgersen]

I can imagine reasonable scenarios for a closed class having less accessible directly derived classes, e.g. a public closed class with internal derived classes. To other assemblies the derived classes are just implementation details (they may get hold of instances of them but can't name their type). But the closed modifier still serves useful purposes:

• Other assemblies can't derive from the closed class
• The declaring assembly still benefits from exhaustiveness

E.g.

public closed record class MyList<T> : IReadOnlyList<T> { ... }
class MyEmptyList<T> : MyList<T> { ... }
class MySingleList<T> : MyList<T> { ... }
class MyLongerList<T> : MyList<T> { ... }

[RikkiGibson]

I do think Mad's point seems reasonable. Achieving "consuming assemblies can't derive" is already possible without this feature, but, disallowing less accessible derived types, does essentially deny exhaustiveness checks for the author, and the workarounds for that would somewhat defeat the point of exhaustiveness.

I think library authors will need to be conscious of the fact, that adding an internal derived class, when you only had public derived classes before, means consumers will no longer be able to exhaust the type. Hopefully, library authors would not find this surprising:

// Assembly1
public closed class C;
public class D1 : C;
class D2 : C; // added later

// Assembly2
class Program
{
    static void M(C c)
    {
        _ = c switch // warning: non-exhaustive.
        {
            D1 => 1,
            // D2 => ... // would error: D2 is inaccessible.
        };
    }
}

---

I also wanted to distinguish one subtlety in this area.

As currently implemented, it's possible to have a derived class, which isn't accessible to the base closed class.

closed class C
{
    static void M()
    {
        new Container.D(); // error: inaccessible
    }
}

class Container
{
    protected class D : C;
}

Should this be allowed?

I'm assuming this isn't possible in Java because of the requirement to list the derived type names on the base. I can try to check later.

Interestingly, our upcoming change to list the derived types in metadata, means that we would actually put [IsClosedType(DerivedTypes = typeof(D))] on the base, even though D isn't accessible. That typeof(D) wouldn't be allowed in source code, but, the compiler is able to ignore the accessibility rules when synthesizing the attribute.

[FaustVX]

Is it possible to have a warning on a less accessible class extending closed class. That way authors will be warned that it may defeat one purpose of closed class and if they really want to do that, they could suppress the warning.