How come

coroutineScope

doesn’t accept a

CoroutineContext

to merge with the parent context?

@ansman You mean

CoroutineScope

? You need to use

withContext

, and the

CoroutineScope

receiver of the passed lamba will have the merged

coroutineContext

.

No, I mean

coroutineScope

. Wanting to do structured concurrency on a specific dispatcher requires this:

coroutineScope {
    withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
        ...
    }
}

You don't need

coroutineScope

in that case. Using

withContext

is exactly what you need.

Of, of course. I forgot

withContext

creates a scope

Actually, allowing

coroutineScope

to be an alias to

withContext

could make sense, although it would be the very same thing. Which naming would you prefer, and why?

coroutineScope

and

withContext

have different semantics in terms of structured concurrency

I agree with Dico, but I also don't like name coroutineContext, although it's semantically correct, it cause a lot of misunderstanding and doesn't help understand the use case of it without reading documentation

I am open for suggestions on better name.

withContext { ... }

without parameters does not look right either.

Do you mean that you think they could be aliases? As in, they do the same thing semantically.

Semantically they are the same. They even share code, but

withContext

does more things to figure out if you are actually changing context.

Then I think I'm confusing this with something else completely

How about

awaitScope

, we already have

awaitAll

, where we pass vararg of Deferred, in this case we pass lambda with receiver that becomes CoroutineScope. Not perfect semantically, but clear that this call will suspend until scope is active

I think I prefer

coroutineScope(context)

what the point of

coroutineScope(context)

? To replace withCcontext? It’s counterintuitive imo, withContext is better name that run some block with passed context, it was there before StructuredConcurrency and scopes