As Gavin has worked through the spec for sealed types, it has shone a
spotlight on one of the messy parts -- implicitly sealed types. I've
got an alternate way to stack this that I think is simpler and still
meets the goals.
First, the goals (which in most cases align, but in some cases conflict
with each other):
Unsealed concrete leaves should not be the default. If we follow the
default strategy that a class declaration gets only the flags that are
declared explicitly (which is generally a good default), it is quite
likely that many subtypes of sealed types will be extensible, when that
was not the intent or understanding of the author. For example, in a
hierarchy like the following:
sealed interface X permits A, B { }
class A implements X { }
class B implements X { }
it is highly likely to be a source of mistakes that A and B are neither
sealed nor final, even though they are co-declared with the sealed
interface. The author may well assume that they are in control of all
the implementations of X methods, when in fact anyone can subclass A and
override those methods.
Avoiding excessive ceremony. If the user had to declare every concrete
subtype as final, this may well be seen as excess ceremony. (This is
the same reason we allow the permits clause to be inferred.)
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.)
These are reasonable defaults, both from avoiding the safety question of
accidental extensibility, and reducing ceremony, but they interact in
some uncomfortable ways. For example, under these rules, its possible
to have an explicit "permits" clause without saying "sealed", which is a
little strange. And it is possible to infer both sealing and the
permits list, which might exceed our nontransparency comfort level.
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).
- 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.
Rationale: This still manages to avoid the "accidental extension"
problem, and addresses both the extension and the ceremony problem where
they are both most severe -- at the leaves. Abstract types (which are
generally fewer in number than leaves) err on the side of explicitness.
So the above hierarchy could be written as above, and A/B would be
implicitly final, as desired. If A or B wanted to permit subtypes, they
would need to be explicitly marked non-sealed (to reopen them), or
explicitly sealed (with or without an explicit permits list.)
I think this stays within the spirit of the goals, but with a little
less magic / complexity.
