Opt-in into API implementation

[qwwdfsad]

This issue is for discussion of the proposal to introduce @SubclassOptInRequired annotation in Kotlin to provide a mechanism to require opt-in for API implementation only.

Proposal PR #319

[nreid260]

This seems like it can be achieved today without adding new primitives:

interface DontSubclassMe {
  @MyExperimentalApi
  fun areYouSureYouWantToSubclassMe()

  fun theRealMethods()
}

[iTob191]

Any reason why OptInRequired was used in the name instead of RequiresOptIn? The latter seems to be more in line with the existing annotation. Suggestions:

• SubclassRequiresOptIn
• RequiresOptInForSubclass
• (RequiresSubclassOptIn)

The first two suggestions share the same term (RequiresOptIn) with the existing annotation which is beneficial for code completion and using the same term also helps to remember the name.

[BlondeHex]

This seems like it can be achieved today without adding new primitives:

interface DontSubclassMe {
  @MyExperimentalApi
  fun areYouSureYouWantToSubclassMe()

  fun theRealMethods()
}

Unfortunately, current experimental/opt-in markers can’t cover all library use-cases. The main use-case for SubclassOptInRequired is when an interface is stable for use but unstable to implement because new methods could potentially be added to this interface.
For example:

• https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-shared-flow/
• https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-core/kotlinx.serialization/-string-format/

Its behavior can’t be achieved using a simple experimental marker.