Refinements for sealed types

Alex Buckley alex.buckley at
Mon Aug 19 20:50:06 UTC 2019

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.)


> 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 


More information about the amber-spec-experts mailing list