You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After some thoughts, we've decided to provide CoroutineScope receiver, but remove suspend modifier from lambda, thus replacing the signature block: suspend (SendChannel<T>) -> Unit with block: CoroutineScope.(SendChannel<T>) -> Unit.
Why so? I see two possible usages of this API:
Integrating with callback-based API as in our KDoc sample. For this reason, one doesn't need suspension (it is even harmful to Java interoperability). CoroutineScope is not required either, but it is present in the implementation anyway (and we cannot get rid of it) and it provides additional safety mechanism as there is no temptation to use GlobalScope
Integration with blocking API, but from the coroutine world. For example:
…pending.
* It allows using flowViaChannel for integration with Java callbacks
* CoroutineScope is provided to provide a lifecycle object (that is not otherwise accessible)
* Suspending use-cases are covered with flow builder
Fixes#1081
Original request: #254 (comment)
Additionally, we should discuss whether it will be
CoroutineScope
orProducerScope
and its relation with not yet discussesscopedFlow
The text was updated successfully, but these errors were encountered: