I've got a language proposal idea for Covered Seal...

# language-proposals

[Jordan Terrell]

I've got a language proposal idea for Covered Sealed Subtyping. I'm not sure what the official process is to submit a proposal or what all is involved in making such a proposal, so I thought I would post this here to get some feedback. Disclaimer: I have fully reviewed and edited this proposal, by hand, but I did use AI to create a draft. I did my best to ensure this isn't slop by reading it many times, making edits, etc. But I just wanted to acknowledge that I did use AI to help. Thoughts?

Covered Sealed Subtyping Proposal.md

[Jordan Terrell]

PDF Formatted version.

[jw]

I believe this would force the usage of modules on the JVM when targeting 17+, since the compiler will automatically emit the PermittedSubclasses bytecode attribute in that case, and the JVM restricts subtypes to either be contained in the same module OR in an unnamed module they have to be in the same package.

[jw]

Oh wait you're actually saying this would be for across Kotlin modules? So that's actually the opposite, it would prevent the use of Java modules and force unnamed modules (while also requiring everything in the same package, a generally-discouraged practice).

[Jordan Terrell]

I wasn’t aware JVM 17+ enforced sealed hierarchies that way. I was thinking of this from Kotlin’s exhaustiveness side, not the class-file/module constraints. Is there any way around that, or is JVM 17+ basically a blocker?

[jw]

Java 17 is what added sealing to the Java language, bytecode, and VM, so Kotlin uses that more-efficient native representation when available.

[jw]

It's faked (and possible to violate) when targeting earlier versions of the bytecode.

[Jordan Terrell]

Bummer. Well, looks like this is dead in the water within 15 minutes. sad panda

[Jordan Terrell]

Thanks for taking the time to give feedback Jake.

[jw]

I've had this problem, too, for what it's worth

[Jordan Terrell]

Well, at least I'm not alone! 😀