Allow sealed interfaces without subclasses

[Brian Goetz]

>> A final class with a private constructor is what you are looking for.
>> Like we have java.lang.Void
> True; My fear is this: Brian Goetz's writeup on pattern matching (
> https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html) talks
> about and https://openjdk.java.net/jeps/8213076 touches on exhaustiveness
> checking. I'm afraid that an exhaustiveness checker won't know that all
> constructors are private or, if it does, won't know that the private
> constructors are never called inside the class.

Your fear is well-founded; it is virtually certain the exhaustiveness 
checker would not identify this case.

> Is there a good reason to disallow this? It does come in handy every once
> in a while in languages where it's possible, especially when trying to
> convince the type checker that a particular combination of patterns is
> impossible.

Can you share some examples of such situations?