Exploring inference for sealed types
Peter Levart
peter.levart at gmail.com
Wed Oct 2 20:43:16 UTC 2019
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>
More information about the amber-spec-experts
mailing list