Sealed types -- updated proposal

[Brian Goetz]

> Allowing public auxillary subtype of a primary sealed type is the sweet spot for me, better than trying to introduce either a nesting which is not exactly nesting or a rule than only works for pattern matching.

It was not my intent to propose something that “only works for pattern matching” (I presume you’re thinking about the treatment of enums in switch, and carrying that over more or less directly.)  I was suggesting something a little broader; if you have a sealed type X, and you import X, you would automatically get X.{A..Z} statically imported where A..Z are subtypes.  This gives you the enum behavior, but more broadly; you can say “new A”, etc.  (We can consider extending this to enums as well, since enums and sealed types have such close affinity.)  This is still less intrusive than public aux types.  

But, even adopting the “enum” behavior might well be good enough, has precedent, and is surely simpler; the place where nesting would bite the most is in switches, and this would provide relief.  

Further, I suspect that the “public aux subtypes of primary sealed type” will be received by the audience more as “glass half empty”; rather than being happy about the new situations where they could use aux types, they’ll be annoyed at where they can’t, or frustrated with the complexity of the rule.  Finally, the arguments against using aux types (findability) have some merit.  So I was looking for something less sharp-edged.  

> I don't understand how "semi-final" can be a good keyword, the name is too vague. Given that the proposal introduce the notion of sealed types, "sealed" is a better keyword.

There’s two sides here.  The connection to finality is powerful, and I like that.  On the other hand, semi-final might sound nonsensical (like “half pregnant”) to some, and silly (because of the pun) to others.  So I’l accept that this is likely to strike some people as “too clever” and cause more than its share of unnecessary whining.  

Contextual keywords are usually OK as modifiers (as long as they don’t want to show up somewhere else), so `sealed` is not terrible.  

In earlier discussions, there was some concern about sealed vs final (Kevin), especially with regard to negation.  I thought about this some more and I think we can say:

 - A subtype of a sealed type is implicitly sealed.
 - If that subtype is a concrete class without a permits clause, then it is effectively final, though not actually final.  (You can say final explicitly if you want the belt-and-suspenders.)
 - You can un-do the inheritance of sealing with “non-sealed”, whether the subtype is a class or interface, abstract or concrete.  So no non-sealed vs non-final confusion.  

> For un-sealing a subtype, "unsealed" seems to be a good keyword.

If the keyword is `sealed`, then I strongly prefer its opposite be `non-sealed`.  (Among other reasons, I don’t want to open the door to having different inversions for different modifiers.)  

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