Interface internal members support: suggestion

Language Design
1

Perhaps we have a restaurant where clients can order exotic Dishes.

interface Dish {
	fun order(): Dish = Cook.cook(this)
	fun cook() // not what you expect to do in a restaurant
}

class FuguFish: Dish {
	override fun cook() = trickyRecipe(this)
}

But what if a client comes up with the idea to cook a Dish herself right in the restaurant since this option is accidentally accessible. The poor restaurant owner should keep an ambulance, a fire brigade, and a lawyer next to the door.

Fun is fun, however, for the time being, I had dozens of real situations when I faced a necessity to conceal interface members from inadvertent use. Of course, there are workarounds like wrappers and helpers. But why add redundancy and entanglement to the already difficult life of a programmer?

Actually, I believe it’s possible to resolve this issue in Kotlin without any significant effort by allowing internal visibility modifier with some specific annotation (like @PublishedApi) that indicates the underlying member is public within JVM. This solution doesn’t require big code changes, keeps Java compatibility, and when eventually this feature will be implemented by Java team no changes required to custom code. Win-win.

For a notice: The similar subject was being discussed here

Feel free to vote for the feature here: https://youtrack.jetbrains.com/issue/KT-22408

1 Like