A lot of classes and functions that we could use to build our own components are

internal

or

private

. I know the reason for limiting the public API but an optIn annotation might be enough. Right now we have to copy huge amounts of code in order to have a working custom component. Code that won't get maintained or fixed easily. If we could opt in to them, our code would break on upgrades but we would still get the benefits and fixes after fixing them.

which classes or functions do you want to have access? I'd imagine it's about drag gestures 🙂

In this case such an API will be effectively public. This will open doors for binary compatibility issues when there are transitive dependencies using the API.

Library developers shouldn't opt in

I think we can't prevent it. My concern is that end users will be affected at the end, and the failure will happen at runtime, which can affect production.

I think there are lint/compiler plugin ways for preventing opt in on library modules.

Buy it is still up to library developers to apply the rule/plugin, right?

They can choose to ignore them.

Ok, I'm not sure what particular rules/plugins you mean, but if there is a way for library devs to use the internal APIs, they will do it. As a result, end users will be silently affected. So this is my concern here.

I completely understand. On the other hand compose-ui modules are different from say coroutine and there are many valid use cases for customizing them.

Experimental API is the API being tested, so there is intention to make it eventually stable.

@Halil Ozercan There has been a few. This one for example https://kotlinlang.slack.com/archives/CJLTWPH7S/p1621754724158200

+1 to everything @Arkadii Ivanov said above. Everything at the layer of compose-foundation and above can be done from libraries and apps without making some of these other internals public, albeit with some additional work.

I'm just saying that having to copy 500 lines, change 3 lines to have a three anchor bottomsheet is not ideal. Maintaining and syncing the libraries/applications with latest upstream improvements would be quite cumbersome don't you agree? I think a more tinker friendly api would be really nice. There might be better approaches than opt in annotations.

I do not agree. 🙂 I think that an API where you can open up the source of its internals and press ctrl+c, ctrl+v, make any alterations you like, and be on your way within minutes is profoundly tinker-friendly

There is also an

@InternalCoroutinesApi

annotation in Coroutines that I encountered today.

/**
 * Marks declarations that are **internal** in coroutines API, which means that should not be used outside of
 * `kotlinx.coroutines`, because their signatures and semantics will change between future releases without any
 * warnings and without providing any migration aids.
 */
@Retention(value = AnnotationRetention.BINARY)
@Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION, AnnotationTarget.TYPEALIAS, AnnotationTarget.PROPERTY)
@RequiresOptIn(
    level = RequiresOptIn.Level.ERROR, message = "This is an internal kotlinx.coroutines API that " +
            "should not be used from outside of kotlinx.coroutines. No compatibility guarantees are provided." +
            "It is recommended to report your use-case of internal API to kotlinx.coroutines issue tracker, " +
            "so stable API could be provided instead"
)
public annotation class InternalCoroutinesApi

Yes, and as it is mentioned in the comment it should not be used. Otherwise issues like this will happen: https://youtrack.jetbrains.com/issue/KT-46697. In this particular case Ktor used there internal API and depended on an older version of coroutines. lucky Kotlin/Native caught the issue at linking time. JVM would crash at runtime. So it is like playing with fire 🔥 🙃

I see your point 🙂