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
