A lot of classes and functions that we could use to build our own components are `internal` or `priv...

# compose

[Saiedmomen]

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.

[Saiedmomen]

One could still not opt in and copy and have a more stable and less up to date repo.

[Halil Ozercan]

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

[Arkadii Ivanov]

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.

[Saiedmomen]

Library developers shouldn't opt in

[Arkadii Ivanov]

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.

[Arkadii Ivanov]

Copy-paste is verbose and inconvenient, but is safe.

[Saiedmomen]

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

[Arkadii Ivanov]

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

[Saiedmomen]

They can choose to ignore them.

[Arkadii Ivanov]

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.

[Saiedmomen]

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.

[Saiedmomen]

On the other hand there are already opt in annotations for experimental api's that have the same issue

[Arkadii Ivanov]

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

[Saiedmomen]

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

[Adam Powell]

+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.

[Adam Powell]

Not all of these internals are designed to be API in the first place; many of them are kind of raw utilities instead of clear, single-purpose concepts. Some of them have changed dramatically in the course of performance optimizations or learning how to write compose code more effectively

[Adam Powell]

Compose wasn't designed and written in waterfall style, a great many of the patterns and best practices documented and promoted today are the result of us trying things out and learning the hard way. 🙂 Some internals still use some patterns that may have been mechanically sound, but we may now favor patterns that are more consistent with what we do elsewhere if we were to promote more into the public API surface

[Saiedmomen]

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.

[Saiedmomen]

like for example having the intent to eventually publicize some of these utilities

[Adam Powell]

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

[Adam Powell]

especially if upstream changes are thereby incapable of breaking your code

[Saiedmomen]

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

[Arkadii Ivanov]

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 🔥 🙃

[Saiedmomen]

I see your point 🙂

[Saiedmomen]

thanks for the clarification