One of my teammates ran into the following problem, which confused me at first until I realized what he did When you type out the code to collect on a flow (fully type out

collect {}

without auto-importing it), it'll default to the

Flow.collect()

method, which should be expected since the extension function

collect {}

was not imported. The problem is that when you do this, there's no option to automatically fix the issue unless you manually add the import statement, or re-type in "collect" but allowing auto-import to do its job. Now that I have seen this issue, I know how I can help my teammates next time, as we continue working with Coroutines/Flow. However, this was a minor point of frustration... So my question is: Is there any plan to rename or remove the

Flow.collect

function so this doesn't happen again? Screenshot is an example of how unhelpful lint is when you find yourself using

Flow.collect()

by accident

This is probably more of an IDE import UX issue than something Flow-specific, I've seen it happen elsewhere as well.

I would agree, except that this issue would happen regardless of IDE. Unless you were keenly aware you needed to import

kotlinx.coroutines.flow.collect

, you would probably try to make use of the class function

collect()

. Not to mention the JB IDE does a great job showing you that you are using an internal API, but just misses by not telling you how to fix it.

that does raise an interesting potential enhancement. if

interface Flow { fun collect() }

were annotated

@Deprecated(
    message = "Use extension function instead",
    replaceWith = ReplaceWith(
        expression = "collect(collector)",
        imports = ["kotlinx.coroutines.flow.collect"]
    )
)

it would help external users, but be annoying to internal users. I wonder if there's some better middle path. may be worth filing a feature request for

Probably a

RequiresOptIn

annotation (

InternalCoroutinesApi

?) once the "lower resolution priority" is implemented ([KTIJ-933](https://youtrack.jetbrains.com/issue/KTIJ-933)). Still would need something in the meantime though.

I mean, why not deprecate the function, and make a new one like

collect0

, which is obviously wrong for consumers of the library, but distinguishable for internal users.

because it's an api that is being used by external consumers (most should not, but there are some users of internal coroutines api). internal api isn't stable, but I think they're not going to bother breaking compatibility here until they have a better replacement