Sealed types

[Mark Raynsford]

On 2018-11-27T17:20:54 -0500
Brian Goetz <brian.goetz at 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