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?

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.

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)