Sealed types -- updated proposal

[Brian Goetz]

> Question about option #3: would it make only direct subtypes of the sealed/switched-on type available in this way, or recursively?

There’s multiple ways to cut this, but the one that seems most aligned with enums is: do this for subtypes (direct and indirect) _that are nested directly in the sealed type itself_.  

More precisely: for a switch on x : T, where T is sealed, allow unqualified type/dtor patterns on cases for T.V where V <: T.  

> 
> I agree with limiting the options to #1 and #3. Between the two of them, I'm a bit on the fence. This is a good feature for enums, and this case is mostly similar, but not entirely; the chance for ambiguous simple names changes a few things. For example, when I add a new subtype to a sealed type that shares its simple name with an existing subtype, I've broken calling code that wasn't qualifying. Also just the need for users to choose whether to qualify or not is a pain.
> 
> However, it is nice that it doesn't "make you" import the type which makes that simple name usable in the entire file including in places where its meaning would be less clear.
> 
> Meh?
> 
> 
> 
> On Fri, Feb 1, 2019 at 9:59 AM Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
> 
> > On Jan 31, 2019, at 4:07 PM, Remi Forax <forax at univ-mlv.fr <mailto: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.  
> 
> 
> 
> 
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com <mailto:kevinb at google.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190201/7facaaf2/attachment-0001.html>