Sealed types

[Brian Goetz]

> Is the intention to allow this:
>
> module M;
> package x.y.z;
> __Sealed interface I { }
> class A implements I {}
> __Unsealed interface B extends I {}
>
> Then, in another compilation unit:
>
> module N;
> package a.b.c;
> class C implements B {}

Yes, unsealing removes all subclassing restrictions.

> ... and then:
>
> module O;
> package d.e.f;
> I x = new C();
> switch (x) {
>    case A: ...
>    case B: ...
> }
>
> The switch should be considered exhaustive, because both A and B are
> direct children of the sealed interface I.

Yes.

> However, it's possible for
> me to add extra subtypes to B because B isn't sealed, and I still get
> exhaustiveness without mentioning C explicitly.

Correct.  A|B is exhaustive over I; if you know about C, you can also 
say A|C|B, and its still exhaustive.

> I would expect the following *not* to be exhaustive:
>
> module O;
> package d.e.f;
> I x = new C();
> switch (x) {
>    case A: ...
>    case C: ...
> }

Correct, not exhaustive.  (Allowed by statement switch but not 
expression switch.)
> I've mentioned modules and packages explicitly above because it's not
> clear to me if explicitly unsealed interfaces are permitted to have
> implementations in different packages or modules without also losing
> exhaustiveness.

Yes.  As mentioned before, I expect unsealing a _class_ to be more 
common than unsealing an _interface_, because classes have more tools 
with which to defend against rogue subtypes.