JEP-360 Sealed types and non-accessible subtypes

[Kłeczek, Michał]

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