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
This is to preserve the same signature of the original functions (async(...) is the same) as in the kotlinx-coroutines library. Except even Roman says that was a mistake and it only exists today for backwards compatibility.
These new functions are a perfect excuse to drop the parameter, except that there are still other uses for that context other than incorrectly specifying the Job, or overwriting the dispatcher. What about passing in a custom exception handler or a CoroutineName for debugging? Or what about other custom CoroutineContext.Elements?
One option would be to add some require(...)'s to the functions, which throw an exception if the passed CoroutineContext contains a Job or a ContinuationInterceptor. This is done in a few places in the Flow api. But then we're introducing a runtime exception instead of a checked one.
Another option might be to ignore any Job or ContinuationInterceptor properties in the passed context, adding a warning to the comments. This has its own issues, since technically we add some complexity to the fold, and if the user doesn't read the comment, they may miss that their Job or ContinuationInterceptor is being ignored when that's what they really wanted.
I'm leaning toward the require(...) but still undecided.
The text was updated successfully, but these errors were encountered:
As of
1.0.0-beta01
, builders such aslaunchDefault(...)
take a first parameter ofcontext: CoroutineContext = EmptyCoroutineContext
. The full code:This is to preserve the same signature of the original functions (
async(...)
is the same) as in thekotlinx-coroutines
library. Except even Roman says that was a mistake and it only exists today for backwards compatibility.These new functions are a perfect excuse to drop the parameter, except that there are still other uses for that
context
other than incorrectly specifying theJob
, or overwriting the dispatcher. What about passing in a custom exception handler or aCoroutineName
for debugging? Or what about other customCoroutineContext.Elements
?One option would be to add some
require(...)
's to the functions, which throw an exception if the passedCoroutineContext
contains aJob
or aContinuationInterceptor
. This is done in a few places in theFlow
api. But then we're introducing a runtime exception instead of a checked one.Another option might be to ignore any
Job
orContinuationInterceptor
properties in the passed context, adding a warning to the comments. This has its own issues, since technically we add some complexity to the fold, and if the user doesn't read the comment, they may miss that theirJob
orContinuationInterceptor
is being ignored when that's what they really wanted.I'm leaning toward the
require(...)
but still undecided.The text was updated successfully, but these errors were encountered: