Hey, I need a CoroutineScope that lives as long as the current composition. is this valid?

@Composable
internal fun composeCoroutineScope(
    coroutineContext: CoroutineContext = SupervisorJob() + Dispatchers.Main.immediate
): CoroutineScope {
    val scope = remember { CoroutineScope(coroutineContext) }
    onDispose { scope.cancel() }
    return scope
}

Looks reasonable to me. I think there’s also a helper coming in dev12 for doing pretty much exactly this. Edit: See Adam’s message.

You might be looking for something more like this: https://android-review.googlesource.com/c/platform/frameworks/support/+/1314778

Ah, that’s what I was thinking of. Just out of curiosity, what could go wrong if you launch before the composition commits?

@Adam Powell would @RestricSuspension and making Composable

suspend

solve those issues?

in what way? Composable functions don't suspend and resume, they fully restart.

RestrictSuspension restricts effects to a receiver which means you can selectively say which methods of a Composable would take state changing or potentially async code and which parts don’t. the std library provides the intrinsics to run suspension without dependencies in KotlinX Coroutines which would allow you run Composable functions with any semantics you want. You control how the continuation proceeds and what suspension points do. Also unlocks the feature you mention since everything mentioned above in terms of optimisations, executions or caching is just a particular runtime for a delimited continuation.

The

launchInCompose

looks cool 👍 but it’s not really what I need. Let’s say I have a presenter that is bound to the life of a

CoroutineScope

(and also created via

CoroutineScope.createPresenter

extension function) and I want to use that presenter for a Composable. Could I use the

effectCoroutineScope

?

otherwise in Kotlin how are you gonna be able to control effects that can go async and scape the main thread. At the moment Kotlin allows those anywhere unless you provide your own restricted suspended implementation

yep, I'm aware, I spent last weekend using exactly those primitives to do gesture detection with compose 🙂 it's quite nice

so the question is why Composable functions are not suspended? what is the reason to make them regular functions?

they're not regular functions either 🙂

suspended continuation can be resumed multiple times

so the resulting structure ends up different

just need to reset the stack labels if your structure is supposed to be immutable

We evaluated it and it wasn't quite what we were looking for, and we spent some time with Roman and his team discussing the parallels between

suspend

and

@Composable

. There are certainly similarities, but ultimately we decided that they were different enough to keep separate

Sure

@Composable
private fun AppScreen() {
    MaterialTheme(colors = AppColors.currentColorPalette) {
        val controller = /*coroutineScope*/.createCounterController()
        val controllerState by controller.state.collectAsState()
        CounterScreen(counterState = controllerState, action = controller::dispatch)
    }
}

How about the presenter code itself? I tend to prefer keeping objects from owning `CoroutineScope`s and instead preferring exposing

suspend

functions as their API surface, which ensures the caller of those functions is what brings a relevant scope along

Well the Controller approach is somewhat of a MVI situation where the Controller lives in by itself (as long as the CoroutineScope) and collectors dispatch actions and receive a state as Flow. Now this was not particularly made for Compose and I am trying to get this to run smoothly with Compose 🙂

Strictly speaking what you're doing will mostly work, though you're over-`remember`ing the scope. You might want to pass the

coroutineContext

supplied as a parameter to

remember

as a key param, so that if the caller changes the context for some reason, you can cancel the old scope and get a new one. That makes the

onDispose

dance you're doing a bit different though

For app code I probably wouldn’t worry about it, but it’s the sort of thing I would want to be very precise about if I were writing a library for wider consumption

Yes, I am currently trying to figure out if using my lib with compose is possible out of the box or if I should provide a way to create a Controller for `@Composable`s without a specific

CoroutineScope

Thanks for your help though! 🙂

Much as I see utility in coroutines, I still would say if someone could really solve composability and concurrency (scoping), they should be entitled to a Genius award. (We should have them in tech: fix this intractable problem and we’ll give you a huge plaque and a million bucks…)