> 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.go...@oracle.com > <mailto:brian.go...@oracle.com>> wrote: > > > On Jan 31, 2019, at 4:07 PM, Remi Forax <fo...@univ-mlv.fr > > <mailto:fo...@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. | kev...@google.com > <mailto:kev...@google.com>
