Hi! maybe someone here can help me, I’ve read this...

# coroutines

[frankelot]

Hi! maybe someone here can help me, I’ve read this article Coroutine Context and Scope by Roman Elizarov a thousand times and I still don’t get why we need a CoroutineScope interface. I get that coroutines builders like launch are extension functions on that class, but why can’t they just be extension function on CoroutineContext instead?

[Jan Groen]

I'm also relatively new to coroutines, so this might not be 100% correct, but here is how I precieve the difference:

Consider that in suspending functions the context can always be accessed through the coroutineContext value. Let's consider a theoretical example of what if launch was an extension function on CoroutineContext. Then we could write code like this:

suspend fun foo() {
    // Do some work

    coroutineContext.launch {
        delay(1000)
        bar()
    }

    // Do some more work
}

Calling the foo method could return, while the code inside the launch method is still active. While this code would work theoretically, it is not ideomatic, because a suspending function is designed to only return when all its work is completed and is not supposed to launch anything else that might complete at a later time. (Paraphrasing the closing statement of the article you mentioned here)

To correct the code above we could do something like this:

suspend fun foo() = coroutineScope {
    // Do some work

    launch {
        delay(1000)
        bar()
    }

    // Do some more work
}

This would lead to the behavior we expect from a suspending function in that it only returns after all of it's calculations are complete.

[frankelot]

Oh Amazing, such a simple explanation 🙂 thank you

[frankelot]

that makes total sense

[streetsofboston]

Also, a CoroutineScope has a CoroutineContext and a CoroutineScope has behavior (eg cancellation, awaiting child job completions, merging parent CoroutineContext into the child CoroutineContext, etc) that a CoroutineContext doesn't have.

A CoroutineContext is just a set of Elements and each Element (eg the Dispatcher, the Job, custom Elements) is-a CoroutineContext itself. You could argue that coroutineContext[Job] could serve as the CoroutineScope...

In other words, it keeps the two concerns apart:
1. cancellation, awaiting child completion, exception handling;
2. context such as current Dispatcher, custom Elements (like ThreadLocal, but for suspend), name (eg for debugging), etc

[frankelot]

(eg cancellation, awaiting child job completions,

Right, an example of cancellation would be what ViewModelScope does in Android and an example of child job completions would be coroutineScope { ... } right