Implement receiveOrClosed for channels and select clause

[qwwdfsad]

We need receiveOrClosed method on top of channels and onReceiveOrClosed for select which will have return type Either<E, CloseToken>.

Currently, pattern to work with channels always has the following form which is clumsy and obfuscates code:

 try {
    source.onReceive { ... }
} catch (e: ClosedReceiveChannelException) {
  // source is closed
}

The better alternative may be

source.onReceiveOrClosed {
  when (it) {
    CloseToken -> // end up consumption
    _ -> // proceed normally
  }
}

For implementation to be efficient we need inline classes (Kotlin/KEEP#104)

[fvasco]

I agree with you, but in my experience the onClose is missing, this can become channel.job.onJoin

[elizarov]

Let me clarify that the considerable fraction of value is going to come from support for onReceiveOrClosed clause in select expression. With that you can write operations on multiple channels with less boilerplate, without having to deal with concurrency, and with ability to code any behavior on the close of any of the source channels.

Note, that when we have channel.job.onJoin you still will NOT be able to use onJoin in select together with onReceive, e.g this:

select {
    channel.onReceive { ... }
    channel.job.onClose { ... }
}

will not work as expected. We shall make sure it fails fast in this case with a clear error message.

Another note, is that we should not actually expose CloseToken in public API, since trying to send this token over another channel will lead to unpredictable results, so we shall encapsulate it by introducing a special ValueOrClosed<T> type (that will be implement as inline class in the future).

[fvasco]

You are right @elizarov
however I still prefer something like:

select {
    channel.onClose { ... } // onClose first
    channel.onReceive { ... }
}

Kotlin/KEEP#104 is WIP, but I cannot understand how is it possible apply to onReceiveOrClosed, the only way to implement a ValueOrClosed<T> is a sealed class (and sealed class cannot be inlined).

[elizarov]

See also this SO discussion https://stackoverflow.com/questions/51463941/how-to-safely-select-across-channels-where-some-may-get-concurrently-closed/

[qwwdfsad]

Will be named receiveCatching and onReceiveCatching, see #974 (comment)

[matejdro]

onReceiveOrClosed implementation mentions that it will not be internal once https://youtrack.jetbrains.com/issue/KT-27524 is fixed.

That bug has been fixed. What is the status for this?

[qwwdfsad]

It will be added to coroutines 1.5.0 under receiveCatching and onReceiveCatching names.

It's already implemented and merged, the rationale of naming is explained in this comment