Sealed types

Mark Raynsford mark at
Fri Nov 30 15:52:04 UTC 2018

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

Mark Raynsford |

More information about the amber-spec-experts mailing list