----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Alex Buckley" <alex.buck...@oracle.com>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Envoyé: Mardi 20 Août 2019 00:22:35
> Objet: Re: Refinements for sealed types
>> 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.
I would prefer "sealed" to be ACC_FINAL in the bytecode and PermittedSubtypes
to list at least one subtype,
basically from the VM POV having an attribute PermittedSubtypes weaken the fact
that the type is final by allowing subtypes.
It may cause some already existing code to run afoul by i think we should try
this runtime encoding and see if it breaks a lot of thing or not.
Rémi
