<div dir="ltr"><div>Question about option #3: would it make only direct subtypes of the sealed/switched-on type available in this way, or recursively?</div><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>Meh?</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 9:59 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Jan 31, 2019, at 4:07 PM, Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br>
> <br>
> You have forgotten that<br>
> - if you have a sealed class (not sealed interface), using nesting has the side effect of creating inner classes.<br>
<br>
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.”  <br>
<br>
And, nested records — the likely common case — will be implicitly static. <br>
<br>
> - for #4, I've proposed a simple scheme that allow tools to find the compilation unit of any auxiliary classes of a sealed type.<br>
<br>
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.  <br>
<br>
Aligning the treatment with enums — which is the other source of exhaustiveness constraints in the language — is a much cleaner move.  <br>
<br>
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.  <br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>