Sealed types -- updated proposal

[Brian Goetz]

> On Jan 31, 2019, at 4:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> You have forgotten that
> - if you have a sealed class (not sealed interface), using nesting has the side effect of creating inner classes.

Kind of a strange way to put it. I would put it as: “the user has the option of nesting both static and non-static classes, as is appropriate to the situation.”  

And, nested records — the likely common case — will be implicitly static. 

> - for #4, I've proposed a simple scheme that allow tools to find the compilation unit of any auxiliary classes of a sealed type.

Everything is possible.  But, it’s a question of cost vs benefit.  I have come around to thinking this is a bigger hammer than the value of the benefit.  And further, a rule like “it would only be allowed for subtypes of a main sealed type” is a pretty serious design smell.  If we’re going to do this, it should be all or nothing, standing on its own, but there is limited appetite for this.  

Aligning the treatment with enums — which is the other source of exhaustiveness constraints in the language — is a much cleaner move.  

For libraries like the JDK, we’ll almost surely bite the bullet and split into separate source files.  This is an acceptable “tax” for the JDK; we pay taxes like this all the time.  There’s a range of other tradeoffs users can make.  


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