> 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.)
