On 2018-11-27T17:20:54 -0500
Brian Goetz <brian.go...@oracle.com> wrote:
> Since we’re already discussing one of the consequences of sealed types,
> let’s put the whole story on the table. These are my current thoughts,
> but there’s room in the design space to wander a bit.
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 {}
... 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. 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.
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: ...
}
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.
--
Mark Raynsford | http://www.io7m.com
