A modern programming language that makes developers happier.

kotlinlang

When there are new experimental features (e.g. context parameters currently), instead of `-Xcontext-parameters` , could we get another option "allow this experimental feature but only for non-public members of the module"?

This way we would still be able to use the feature (e.g. context parameters) inside a compilation unit, where binary compatibility doesn't matter.

I’d put this in BCV or some other post-processing step.

Something I’d love to see as well is a tool that fails my build if I’m using a Kotlin-only feature (default parameters, extension functions, …). To make sure my lib stays 100% compatible with Java callers.

&gt; I’d put this in BCV or some other post-processing step.
Whatever, as long as it's easily configured in KGP. Since BCV is being merged there, why not.

&gt; Something I’d love to see as well is a tool that fails my build if I’m using a Kotlin-only feature (default parameters, extension functions, …).
None of these features break Java usage though. Even if you have a feature that does break Java usage (e.g. `suspend`), you can still provide an overload that returns a `Future` or whatever, the existence of a `suspend` function does not make the entire lib unusable from Java.

Yes. For Java-compatible libs, I’d like the special symbols (suspend, extensions, …) be the exception and require and opt-in marker, not the other way around.

Extension functions and default parameters do not break java usage but they can sure make it a bit awkward