Refinements for sealed types

[Brian Goetz]

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

Currently, yes.

> 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.
It's more about reading than writing.  Having both the sealed-ness be 
implicit, and the permits list be implicit, puts a lot of strain on the 
_reader_.  (Yes, Javadoc will spell it out, but source readers may not.)

>
>> 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?

implicitly effectively final, at least.  Whether it is _actually_ 
ACC_FINAL is a separate matter.