Exploring inference for sealed types
peter.levart at gmail.com
Wed Oct 2 20:43:16 UTC 2019
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts