What’s the reasoning that

Channel<T>

and

Flow<T>

don’t share the same backing interface? It seems unfortunate that the two won’t be able to share the same operators

What do you think they have in common and what operations this interface shall support?

You originally stated that one of the goals was that they would both share the same interface so an operator for one would work for the other. I would imagine that you guys encountered a good reason as to why you decided to reverse course on it - was just curious what that reason is

Flow does not emit anything, it accepts consumer.

Sure, but as a user of the API, I see both

Flow<T>

and

Channel<T>

as a way to consume multiple values of

T

over time

You mean

Flow

and

ReceiveChannel

. They are still different as consuming or iterating a channel doesn't share the scope with the producer (and the produced may not even be in a coroutine at all), while a

Flow

collecting coroutine will share its scope with the emitting collector, passing any failures through. Also, a

Flow

emitting collector can always throttle the collecting coroutine, which is not the case for

Channel

.

oh yeah, my bad.

Flow<T>

and

ReceiveChannel<T>

, not

Channel<T>

We came to think they are too different to share an interface. Channels are single use, hot, and must be consumed, while flows are multi-use and cold. So you need to be explicit when converting them using

asFlow()

.

@elizarov There's no

asFlow()

extension for

ReceiveChannel

as of kotlinx.coroutines 1.2.1

There is

asFlow()

on

BroadcastChannel

Sure, and crazy how simple it is, but is there a reason it is not in kotlinx.coroutines?

Name and contract. What happens if you do it multiple times? Shall it be named

consumeAsFlow

? Etc....