Refinements for sealed types
Brian Goetz
brian.goetz at oracle.com
Mon Aug 19 22:22:35 UTC 2019
> To be clear, infer `final` on A. We were already inferring `sealed`
> last week; the new thing this week is to infer A's `permits` list as
> empty (giving A an overall score of implicitly `final`) rather than
> "any co-declared subtypes of A". Given the code above, it is a
> compile-time error for any class in any compilation unit to attempt to
> subclass A.
I don't have a strong opinion on whether "sealed but no permitted
subtypes" is a habitable space separate from "final", but I'm fine to
say "that means final" for most purposes. Not sure what reflection
should say; is it OK for a type that is clearly sealed in its
declaration to report back as "not sealed, but final?" Or does that
mean it is both sealed _and_ final (an empty PermittedSubtypes
attribute, plus an ACC_FINAL)? Similarly, depending on where we land on
this decision, it affects the binary compatibility consequences (e.g.,
is it binary compatible to go from final to sealed (with or without any
permitted subtypes)?
> Where this is all headed is that we never infer `sealed` with a
> non-empty `permits`. As you said, no need for `permits none`. It is
> good to draw a clear distinction between
> `sealed`-with-at-least-one-permitted-subtype versus
> `final`-with-zero-subtypes.
I'm fine with this, modulo above details-to-be-worked-out.
More information about the amber-spec-experts
mailing list