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.
