Refinements for sealed types

[Alex Buckley]

On 8/15/2019 10:38 AM, Brian Goetz wrote:
>      sealed interface X permits A, B { }
>      class A implements X { }
>      class B implements X { }
> 
> In the current design, we took the following path:
> 
>   - Subtypes of sealed types are implicitly sealed, unless marked 
> non-sealed.
>   - We infer a permits clause when it is omitted, which is possibly 
> empty (in which case the type is effectively final.)

So, A is implicitly sealed, but (IIRC) its lack of `permits` means that 
any class which is in the same compilation unit as A and which says `... 
extends A` is a permitted subtype.

And, you are saying that it's not reasonable for A's author to have to 
oversee the whole compilation unit all the time, just in case some 
permitted subtype is lurking around with a `non-sealed` modifier that 
lets the X hierarchy be polluted yet further.

> So, let me propose a simplification:
> 
>   - A concrete subtype A of a sealed type X, which has no permits 
> clause, no known subtypes, and is not marked non-sealed, is implicitly 
> sealed (with an empty permits clause).

Sounds good -- and where "implicitly sealed (with an empty permits 
clause)" === "implicitly final", right?

>   - Any other subtype of a sealed type must either have a "sealed" 
> modifier, or a "non-sealed" modifier.
>   - Any type with a permits list must have a sealed modifier.

Alex