JEP-360 Sealed types and non-accessible subtypes

[Kłeczek, Michał]

I have just realized permits clause is in fact optional. Optionality is 
though only a syntactic sugar to save some keystrokes.
I think it might be useful to change its semantics to mean any type in 
the same module and not just the compilation unit.

Thanks,
Michal

On 01/12/2019 12:36:54, "Kłeczek, Michał" <michal at kleczek.org> wrote:

>Hello,
>
>I would like to ask about JEP-360 proposal in the context of "module 
>implementation only types"
>(ie. public types that can only be extended/implemented by types in the 
>same module).
>
>Right now there is only limited support for this: one can define a 
>public abstract class with non-public constructor.
>
>Sealed types seem to provide such a feature but IMHO there is a couple 
>of concerns:
>
>The syntax requires to explicitly list all permitted subtypes.
>It could be possible to make permits clause optional. Omitting it would 
>mean "all subtypes in the same module".
>I admit such syntax is just a nice to have as explicitly listing 
>subclasses is not such a big deal
>when all types must be in the same module anyway.
>
>What is interesting though is the interaction of permitted types 
>declaration and exhaustiveness check:
>how should it work in case when a public sealed type permits a 
>non-public/non-exported type?
>
>Introduction of exhaustiveness check also means adding a new permitted 
>subtype is an incompatible change
>- similar to adding a value to existing enum.
>This makes it somewhat less useful for the module implementation only 
>types use case.
>The solution might be to have sealed types without explicit permits 
>clause (see above) and
>such types could not be used for exhaustiveness checks.
>
>Kind regards,
>Michal