I’m getting an error when trying to collect a flow. This seems odd:

GlobalScope.launch {
    flow.collect {
    }
}

I’ve found other examples where a lambda works as a flow collector.

It happened to me the other day. It seems like the IDE is not passing the compiler the latest greatest version of the file. Maybe the file is out of sync. Refresh the IDE or cut the code and paste it again.

I’ve tried just about everything.

You need to import the collect extension function.

Collect isn't an extension function I think

There are two versions of

collect

, an instance method and an extension function. For your collecting code, you'll mostly use the extension function variation. That part was not well designed. And the (auto) import facility of the IDE doesn't help either....

Please, use start imports with Kotlin to avoid problems like that in the future.

star imports (i.e.

import kotlinx.coroutines.*

,

import kotlinx.coroutines.flow.*

)

On most team's code style guidelines that I've been working on, star imports are actively discouraged (usually auto-converted to regular ones)....

I personally prefer non star imports too, unless the packages are well known. The Android official style guide is no star imports BTW. Personally, I'd like an agreement between Google and JetBrains on which packages to allow star imports by default (packages from kotlinx.coroutines would be part of this).

I don't understand that star imports are actively encouraged to make working with official libraries easier. Star imports make it harder to reason about where a function is coming from. If the IDE came with default settings to automate this, that would indeed be better. But not everyone (as is evident) wants to use star imports. I suggest that extension functions are imported automatically alongside classes if they are declared on the same file, for a start - and then indicate the file as a class in Intellij so as to not discourage using extension functions.

Star imports are not required, but really improve usability of Kotlin DSLs that are usually based on extension-centric design when most of helpful functions are not members, but extensions. No star imports policy indeed makes sense in Java, where a typical class that you import might have 100s of members you get all at once with one-line import, but it does not make a lot of sense in Kotlin where a typical package might have just a single class (e.g.

Flow

) and 100s of extensions, each of which needs a separate import.

It makes sense for the flow package, but it requires that I configure my IDE (requiring know-how) to always use * import for that package. By default, "optimizing imports" from the ide will replace it with normal imports again. Unless the defaults were changed and I never knew, the usability of this is quite lacking. Therefore, I think you will get this question over and over again. Following up on that, to import * feels like a workaround for a missing or incomplete language feature to me personally.

It’s not just coroutines lib. All Kotlin libraries usally work better with star import. However, if you use a lot of Java in your project, you might not find that convenient. I wonder how we can improve it. Do you have any specific ideas?

Yeah, I suggested that extension functions from the same file or package (tbd) are imported alongside the type they extend. As an example (assuming it works on the whole package), if you import

kotlinx.coroutines.flow.Flow

, You would get all extension functions of Flow (vast majority of operators). This makes sense because the extension functions are used as members of

Flow

syntactically. Then you just need to import

flow {}

or

channelFlow {}

if you use one of those, which makes sense because they are not used as members.

Oh yes, importing all the extensions from the same package of the imported type is a great idea that I think I'd enjoy having.

Perhaps it should work on modules rather than packages

I don’t see how that’s much different from star imports.

I thought the jetbrains style guide prohibited * imports. If not the jetbrains style guide, the Android kotlin style guide definitely does. And tools like ktlint don’t have a way that I know of to override them. APIs requiring star imports to be usable seems like an obvious anti-pattern.

In application code (not library), you'd not get everything imported, but only the extensions for the same package as the type. That'd make the code more understandable. Remember than many people, including me, are reading Kotlin code in a browser without cloning the whole project and waiting for Gradle sync and IDE indexing. Than means no cmd/ctrl hovering info. Same when code is read on mobile. I dislike star imports on all the code because of how negatively it impacts readability where new libraries or packages are used. That's why I'd like to have them only on exceptions like Kotlin flows, and I think the language should help library developers like you add this. I'm not sure such a tool should be given to everyone though, or if it is, it should be opt-in, maybe with the exception of select kotlinx and androidx libraries.

Kotlin, the language, and its libraries are designed with start imports in mind. If standard library weren’t imported by default, you’d have the same issue with it. Any Kotlin DSL would look ugly without star import. However, indeed, when you work with Android, which is mostly Java, you should prefer Java-style single-class import, since in Java a class is usually a single unit of an API. In Kotlin a single unit of API is usually a package. I can only think of solution that would somehow distinguish Kotlin/Java packages or classes and make imports individual or star depending on that.

I like the idea. This would require not only a change in the IDEA (put intended), but would need some serious publicizing to the larger dev community as well (to change their Lint rules, review/PR practices, regarding star-imports).

@streetsofboston This realization should come gradually as people move from using Java-centric APIs (where every API is a class) to to Kotlin-centric APIs where top-level functions rule and a typical API is a package.

@jw ^^ If star imports are important from @elizarov’s perspective, I think it’s important to get alignment in the Android coding styles so the code style checkers can be updated as well. Currently the Android style guide doesn’t allow wildcard imports.

It's extremely unlikely to be changed. Star imports are for people who use text editors. They're not needed in a world of IDEs and Kotlin is not usable without an IDE.

@elizarov ^^ this makes things difficult from my perspective then. To be fair, I’ve been using Kotlin as my primary language for 3 years now. This is the first time I’ve had a problem specific to star imports.

Just because stdlib is auto-imported. We can “solve” it by having coroutines and flow auto-imported, too, but I don’t like this kind of “solution” (it does not scale to be big Kotlin libraries ecosystem)

But that's already the behavior with 99% of the code I work with since it's not the stdlib.

No star imports policy makes Kotlin programming experience less fluent than Java one. In Java a unit of API is typically a class. You import it once to say “I’m using this API here” and you’re done. In Kotlin a unit of API is often a package. With star imports in Kotlin you also import it once to say “I’m using this API here”. That’s why in Kotlin libraries team we have “star imports” policy.

I think that conjecture lacks proof

Which conjecture? The one about Java vs Kotlin fluency or the one about Java vs Kotlin API design style?

There's not necessarily one kotlin api design style

Quantity of imports doesn't make a difference since the IDE manages them all.

That was actually the problem. I was finding that the IDE wasn’t offering the

collect

import. Perhaps that’s where this can be addressed. What I was hearing from @elizarov was that the only way it will work naturally is with wildcard imports.