Since I got a few questions on this, let me step back a bit further and
shed some light on these requirements.
Sealed types are really *two* features in one:
- Declaring a sum type, so that the sum constraint is visible to the
compiler as a source of exhaustiveness in flow analysis (e.g., switch
totality.)
- A more refined notion of "final", that allows class authors to be
able to reason about "I know where all the implementations of this type
are".
While the two fit (mostly) neatly into the same package, they serve very
different audiences. Many of the comments and questions we've gotten
basically come down to assuming that one of these use cases is the
"real" design goal, and the other is just a lucky accident.
Users will, hopefully, declare sums (often sums of records) in all sorts
of places. These folks generally don't care about "I know all the
implementations", because these classes often have no nontrivial
implementation, they are data carriers.
Platform developers are more likely to use sealing as a means of
building safe APIs. Think of how many classes are final -- for good
reasons -- but we later wished there could be multiple implementations.
APIs like ConstantDesc are a primary example of the second sub-feature;
we want to expose polymorphic APIs, but control the implementations.
(Historically we have resorted to using abstract classes with non-public
constructors for that, but this is obviously a suboptimal move.)
In that light, wanting to infer the permitted subtypes when they are
co-declared is reducing ceremony for users of SubFeature 1, and and
wanting to avoid accidental unsealing is an important safety feature for
users of SubFeature 2.
On 8/15/2019 1:38 PM, Brian Goetz wrote:
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.
