Not sure the right channel to ask this — in many K...

# coroutines

[Patrick Steiger]

Not sure the right channel to ask this — in many Kotlin libraries we often see an internal subpackage. What is it for? I mean, isn’t putting internal visibility stuff in the root package the same?

E.g
kotlinx.coroutines.flow
kotlinx.coroutines.flow.internal

What problem does this solve?

[mkrussel]

I don't know about coroutines specifically, but sometimes people put things with a public visibility in an internal package because it needs to be public for other modules of the library group but not public to consumers of the library group. This would normally also be followed with an opt in annotation. I've also done this do to expect/actual requiring something to be public, because the actual is a typedef to a public class.

The other possibility is create something like a package-private, which Kotlin doesn't have. So the thought would be only code in flow or flow.internal should access code in flow.internal. It would be easy to create a static checker to enforce something like that.

[elizarov]

Yes to the above. This is a standard pattern for big libraries (big as in “consisting of multiple packages”). On JVM (without JPMS) you cannot really forbid 3rd parties from using your “module-private” parts (since they are all have to be public), so naming the corresponding package internal (sometimes impl is also used) hints that those are not supposed to be used outside. With JPMS you can enforce it, but it also requires you putting all those declarations into a separate package (that you will not export from your library)