What’s the best way to get the “current scope” for a suspend function? In other words,

suspend fun foo() { async { ... } }

. I’d like to use async inside foo, and inherit from whatever scope foo was called with.

have

foo

be an extension function of

CoroutineScope

because of how structured concurrency works, you can only start async tasks with a lifetime as long as

foo

. to enforce this, kotlin only offers the

CoroutineScope

in suspend functions via `coroutineScope { }`:

suspend fun foo() {
  coroutineScope { async { ... } }
}

This means that

foo

won't return until the async task completes. Or, you can have

foo

be an extension on

CoroutineScope

, but then it shouldn't be a

suspend

function, and should not use any suspend operators of its own (except inside of whatever coroutine you launch on the provided scope)

So is this discouraged,

suspend fun CoroutineScope.foo() { delay(1000) }

yes, because it's not clear which context the function uses

I’m just trying to understand your last comment, so is this discouraged:

fun CoroutineScope.foo() { delay(1000) }

that won't compile 🙂

I guess that discourages you against doing it then

It's pretty clear which scope it uses as an extension function. It uses whatever scope you call the function from, which is exactly what the original question asked. Using

coroutineScope{}

will create a brand new scope/sub-scope

Sam: yes, that's exactly the idea

I guess I can’t use CoroutineScope as an extension because inside that extension function I have no way of doing further suspendable calls ?

Matt: if you're referring to

suspend fun CoroutineScope.foo()

, I was talking about context, because

suspend

functions have

coroutineContext

, as does the scope.

Thanks @octylFractal and @withoutclass

@octylFractal I'm interested to find out where you read that, I'm not seeing it in the guide: https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/coroutines-guide-ui.md#structured-concurrency-lifecycle-and-coroutine-parent-child-hierarchy

hmm, I guess they do have examples for it -- I was going off of IntelliJ's warnings for it, which given that they come from the Kotlin plugin and therefore the Kotlin team, I assumed they had some reasoning behind it -- I've never had a need for it personally, so I accepted it as a "bad" practice

I've never seen them myself but good to know

regardless, I think it goes against structured concurrency -- if you're making a

CoroutineScope

extension, it should return some form of `Job`/`Channel`/etc., something that can cancel all coroutines started from that function. If you're returning that, you've already opened a new scope (with

launch

,

async

,

produce

, etc.) to call suspend functions in, and don't need the

suspend

modifier for any of it. The only time I could see use for it is when you want to keep the same thread for some other suspend function you call outside of what you use the scope for, but that's extremely niche.

Every new coroutine/action started in the derived scope would be automatically cancelled provided the original scope wasn't a supervisor scope.

launch

,

async

, and

produce

are coroutine builders, they don't create new scopes.