allow permits keyword for sealed class declarations (and interfaces)

[CosminSontu]

Java allows defining sealed classes and interfaces.
With JEP-409 Java introduced the ability to specify exceptions (classes that can actually extend/implement the sealed classes/iterfaces) via permits keyword.

This feature is not that complex and offers quick gains in terms of pattern matching exhaustiveness.
Would this be a relatively easy to implement language feature that would provide quick wins while also avoiding unnecessarily complicating the language syntax?

I know it's a Java feature, but it's good. No worries, Java borrowed from C# lots of recent features so this is actually returning compliments.
PS: I have done a search for similar issues but in case I missed those, feel free to point them out.

[CosminSontu]

the conept could be extended to structs for uniformity.
Spotted this issue post-factum: #485. No mention of Java's approach so maybe this is useful...

[huoyaoyuan]

Note that the word "sealed" means completely different thing in C#.

[CosminSontu]

A beautiful side-effect of a sealed/permits - based inheritance hierarchy is that
implementing a sealed class (because you are permitted to :) ) you now have the following options:

1. to disallow further specialization, by just using sealed modifier (without permits)
2. to allow further specialization but within specified permitted implementations (with permits)
3. to allow unbounded specialization by not specifying sealed at all. ( here pattern matching would ask for a wildcard match arm ...)

[HaloFour]

This is something I really like about Java's approach, it allows further extending from the permitted cases to create a hierarchy but still retaining the exhaustiveness checking.

[KennethHoff]

Is this problem space also solved by discriminated unions? Personally I think this is a very clever solution to the problem of exhaustiveness, but does it add anything else that's not also covered by union types, which is actively on the working set and additionally allows for "closed type hierarchies" of types you do not personally own.

How would this interact with extension interfaces? Could you create a sealed interface hierarchy containing extension interfaces? That's basically a type union right there 😜

[HaloFour]

There is a lot of overlap. This is how Java chose to implement ADTs. For "reference-based" DUs, a closed type hierarchy fits the bill nicely. But closing that hierarchy without a feature like "permits" forces a convention on how that hierarchy would be defined. The current proposal inclused nested types which are sealed, forbidding further extension, which Java does allow.

[CosminSontu]

The question is... Is this something that could land sooner than Roles and Extensions while not causing any interference... while allowing Roles and Extensions enough time and space to evolve?
Sealed/permits seems to be compatible with roles at least...

[jos3s]

Any updates on this feature? Studying a few months ago I found a case that would like to have this possibility that java offers, but I did not find much information about its equivalent in C# until I found this discussion

[CyrusNajmabadi]

@jos3s we're looking at exhaustiveness in our DU efforts.

[nathan130200]

One good thing i found in JEP-409 is about extending StringBuilder. When i need reuse string builder (eg.: some kind of StringBuilderPool) i need implement a wrapper class that holds a StringBuilder reference via some property or Get method, because in C# string builder is a sealed type.