Exploring inference for sealed types

[Peter Levart]

Hi,

On 9/24/19 8:34 PM, Brian Goetz wrote:
> So one sensible increment atop the baseline is: (A) if a top-level 
> type is explicitly declared sealed, and has no permits clause, we can 
> infer the permits clause from the subtypes in the compilation unit (or 
> more narrowly, the _nested_ subtypes).  This is simpler than the full 
> scheme outlined, while addressing the biggest case that concerns me -- 
> the high-fanout case.
>
> The above scheme could be incrementally extended to (B) any class 
> explicitly marked `sealed` -- if you say sealed and leave off 
> `permits`, the permits list is inferred from the current compilation 
> unit.  This seems defensible. 

Is compilation unit really the right choice to base inference on?

For example, a program may be composed of several modules compiled all 
at once in a single compilation unit (javac supports that). This same 
program may be compiled with a build system such as Maven, which 
compiles each module separately as its own compilation unit. Would we 
really want the semantics of a program (or successful compilation 
thereoff) depend on the choice of the build tool?

What about using (module, compilation unit) as the base to perform 
inference within? I understand that compiler may only infer things 
within a compilation unit and module is usually compiled as a whole in 
one compilation unit (possibly together with other modules).

Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191002/41384850/attachment.html>