Refinements for sealed types

[Brian Goetz]

> So if everything is explicit, we want
> - all sealed types to defines their permit clauses
>  (so we need a kind of "permit none" if no subtypes is allowed ?)
> - all subtypes of a seal types to explicitly says if there are sealed or non sealed (to avoid accidental unsealing). 
> 
> am i right, or am i missing something ?

Yes, this is basically it.  I don’t think we need “permits none” because a sealed type with no permitted subtypes is effectively a final type, and only makes sense for concrete classes, so that’s a final class.  

> There are several ways to reduce the ceremony
> - implicit declaration of sealed subtypes if the super type is sealed
> - implicit declaration of permit clauses
> and we may want to choose one, the other or both.


Right.  Now, some observations:

 - We have two cases (sum types, and restricted hierarchies), and two goals (ceremony management, and safety/clarity);
 - Implicit sealing of subtypes by default serves both goals and both use cases, but asymmetrically; it provides ceremony reduction for the sum types case, and safety for the restricted hierarchy case.  
 - Ceremony reduction is far more important for the “sum types” use case than for the “restricted hierarchy” use case, for several reasons.
 - Implicit declaration of permits clauses provides ceremony reduction for the sum types case.
 - Both forms of ceremony reduction start to cross over into being liabilities for the restricted-hierarchy case, because readers should have full information about the hierarchy shape.
 - Most sum types will be co-declared;  many restricted hierarchies will not be.

So, given all this, we should focus all our ceremony-reduction on the case of co-declared sum types.  Which is mostly what I think I was suggesting:

 - Infer the permits clause when all the subtypes are co-declared;
 - Infer “final” for leaf classes in a sum type;
 - Require explicitness in both sealed/non-sealed, and permits clause, in other cases.

We could tighten this further, which probably makes sense:
 - Infer the permits clause when the subtypes are co-declared;
 - Infer final _when the current class is a subtype of a sealed type in the same compilation unit, and has no subtypes_ (again, co-declared with its parent);
 - Require explicit sealed or non-sealed in all other cases;
 - Require explicit permits clause in all other cases.

So this focuses the magic on co-declared hierarchies.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190818/ccf02269/attachment.html>