use-like extensions on ReceiveChannel and SendChannel

[elizarov]

So, we have ReceiveChannel and SendChannel

• If you've done working with SendChannel you should close it (send termination message)
• If you've done working with ReceiveChannel you should cancel it (indicate that you no longer planning to receive anything and sending coroutine should be cancelled).

Currently we have ReceiveChannel.consume extension. The design goal behind it was that it shall "consume" channel by making sure it is always closed at the end. However, it is inconvenient in two aspects:

• Unlike Closeable.use it provides the channel as this. This seems to be a bad design decision in retrospect.
• If consuming coroutine crashes with exception, then it cancels producer with the same exception. It is not clear if that is good or bad idea at the moment.

We don't anything similar for SendChannel channel.

It looks like we should define some additional use-like extensions and ReceiveChannel and SendChannel that cancel and close then correspondingly and provide the corresponding channel in the use-style, so that you can chain channel-producing operators like this:

doSomethingThatProduceChannel(...).use { chan -> ... }

But we cannot name both ReceiveChannel and SendChannel extension as use and they would conflict on Channel interface. It would be great is ReceiveChannel extension was actually named consume but we cannot easily retrofit existing consume so that it provide channel as a parameter instead of this in a backwards-compatible way.

This is an open question on what to do.

[kevinherron]

Deprecate consume, introduce drain with channel as parameter?

[elizarov]

@kevinherron drain is nice name. Thanks for the idea.

[qwwdfsad]

Since 2018 we have introduced a lot of primitives that replace the SendChannel for most of the use-cases: produce, callbackFlow, StateFlow and SharedFlow.

Closing as no longer relevant