Within a body of a `suspend` function, shouldn't t...

# coroutines

[nwh]

Within a body of a suspend function, shouldn't the current CoroutineScope be accessible? Since it had to be invoked from some type of scope?

[louiscad]

@nwh It's recommended to make a child scope, with coroutineScope { … }. Does this fit your use case?

[nwh]

I suppose. Honestly, I think I'm getting confused here. Isn't a CoroutineScope basically just a fancy Job with a bundled context for convenience?

[louiscad]

You can see it this way, but the Job is actually part of the coroutineContext that the scope provides

[Mark]

Is it correct to say: the coroutineContext provided by the coroutineScope{} is the same as the coroutineContext used to call the suspending function, and the Job is a child of the Job representing the call the suspending function?

[louiscad]

It's not exactly the same as its job is not the same, but a child one

[Dico]

I once wondered why they didn't just use CoroutineContext in the place of CoroutineScope. But it makes sense, you can't just add scopes together and stuff.

[nwh]

I'm still struggling with the difference between CoroutineContext and CoroutineScope - I get the technical difference, but not in practice

[Mark]

Same here. It’s the conceptual difference that is not clear to me.

[DALDEI]

My take on this (after being totally lost for a while) is the introduction of a new term 'Scope' which implies very much like DSL contextual 'Scope.' A CoroutineScope is a "DSL LIke" container which injects a coroutine context into the calling textual scope much like say let {} or with {}

[DALDEI]

This then lets all sorts of magic happen by adding properties to the scope which append, ammend or override parent properties of the same name.