Refinements for sealed types

[Alex Buckley]

On 8/19/2019 11:52 AM, Brian Goetz wrote:
>>>> How do you know from `sealed class X {}` and the rest of its 
>>>> compilation unit that all X's subtypes are co-declared? 
>>>
>>> By co-declared, I mean "in the same compilation unit."
>>
>> The emphasis should be on the word "all", not "co-declared". How do 
>> you know that ALL of X's subtypes are declared in the same compilation 
>> unit?
> 
> Here's what I'm suggesting.
> 
> If you say
> 
>      sealed interface X { ... }
> 
> with no permits clause, then the permits clause is inferred from the 
> contents of the compilation unit, which is _by definition_ all the 
> permitted subtypes.  (If there are no subtypes in the current 
> compilation unit, a warning may be in order.)

OK.

> Similarly, if you have a subtype of X:
> 
>      sealed interface X {
>          class A implements X { }
>      }
> 
> that is _in the same compilation unit_, then we will infer `sealed` on A 
> unless you say otherwise.

To be clear, infer `final` on A. We were already inferring `sealed` last 
week; the new thing this week is to infer A's `permits` list as empty 
(giving A an overall score of implicitly `final`) rather than "any 
co-declared subtypes of A". Given the code above, it is a compile-time 
error for any class in any compilation unit to attempt to subclass A.

Where this is all headed is that we never infer `sealed` with a 
non-empty `permits`. As you said, no need for `permits none`. It is good 
to draw a clear distinction between 
`sealed`-with-at-least-one-permitted-subtype versus 
`final`-with-zero-subtypes.

Alex