https://kotlinlang.org logo
#flow
Title
# flow
b

baxter

05/07/2021, 4:51 PM
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
r

rnett

05/07/2021, 9:52 PM
This is probably more of an IDE import UX issue than something Flow-specific, I've seen it happen elsewhere as well.
b

baxter

05/07/2021, 10:53 PM
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.
e

ephemient

05/08/2021, 1:10 AM
that does raise an interesting potential enhancement. if
interface Flow { fun collect() }
were annotated
Copy code
@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
r

rnett

05/08/2021, 2:21 AM
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.
b

baxter

05/08/2021, 3:48 PM
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.
e

ephemient

05/08/2021, 4:16 PM
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
3 Views