Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

onReceiveOrNul extension convenience #1676

Closed
elizarov opened this issue Nov 27, 2019 · 1 comment
Closed

onReceiveOrNul extension convenience #1676

elizarov opened this issue Nov 27, 2019 · 1 comment
Assignees

Comments

@elizarov
Copy link
Contributor

Message from Thibault Seisel in public Slack: https://kotlinlang.slack.com/archives/C1CFAFJSK/p1574860187023800

Since ReceiveChannel<T>.onReceiveOrNull has been deprecated, it is suggested to replace it with the onReceiveOrNull extension function.But I find that it's surprisingly hard to use that
function: Since there is a member property onReceiveOrNull it takes precedence over the extension. Since onReceiveOrNull is a function, the block passed as select clause is incorrectly interpreted as an extra lambda parameter. While the following workaround code works:

import kotlinx.coroutines.channels.onReceiveOrNull as onReceiveOrNullExt
select {
    channel.onReceiveOrNullExt().invoke { foo ->
        [...]
    }
    anotherChannel.onReceive { bar ->
        [...]
    }
}

It is not as convenient as the original Select API. Wouldn't it be better to convert that extension function to an extension property with a different name ?

@DeedleFake
Copy link

Thank goodness for this issue. I was running around in circles trying to figure out how the heck I was supposed to check if a receive was from a closed channel. All of the docs just use onReceiveOrNull, but I can't actually use it because it's marked deprecated. So I tried onReceiveOrClosed, since the docs said that that was O.K., too, but that one's marked as only being for internal use in kotlinx.coroutines. So I tried the extension function, which was a bit of a pain to find as well, and then that one simply didn't seem to work at all. The compiler kept giving me issues about it not taking any arguments.

At the very least the docs need fixing, and badly. The fact that the most prominent documentation for how to actually handle this is an unanswered, open issue that's been sitting here for just under a year is rather disappointing.

qwwdfsad added a commit that referenced this issue Mar 26, 2021
    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as replacement in our own operators

Fixes #1676
qwwdfsad added a commit that referenced this issue Mar 26, 2021
    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as replacement in our own operators

Fixes #1676
qwwdfsad added a commit that referenced this issue Mar 27, 2021
    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as replacement in our own operators

Fixes #1676
qwwdfsad added a commit that referenced this issue Mar 27, 2021
    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as replacement in our own operators

Fixes #1676
qwwdfsad added a commit that referenced this issue Mar 27, 2021
    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as replacement in our own operators

Fixes #1676
pablobaxter pushed a commit to pablobaxter/kotlinx.coroutines that referenced this issue Sep 14, 2022
…in#2612)

* Deprecation and migration of receiveOrNull and onReceiveOrNull.

    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as a replacement in our own operators

Fixes Kotlin#1676
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants