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.
