-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Comments
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 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. |
* 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
* 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
* 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
* 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
* 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
…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
Message from Thibault Seisel in public Slack: https://kotlinlang.slack.com/archives/C1CFAFJSK/p1574860187023800
Since
ReceiveChannel<T>.onReceiveOrNul
l has been deprecated, it is suggested to replace it with theonReceiveOrNull
extension function.But I find that it's surprisingly hard to use thatfunction: Since there is a member property
onReceiveOrNull
it takes precedence over the extension. SinceonReceiveOrNull
is a function, the block passed as select clause is incorrectly interpreted as an extra lambda parameter. While the following workaround code works: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 ?
The text was updated successfully, but these errors were encountered: