CoroutineContext context parameter in suspend functions

[nikitabobko]

This thread is a discussion around a new proposal on bridging context parameters and CoroutineContext together.

The proposal text

[SPC-code]

I like the proposal in general, thought I think that the main point (that suspend function modifier adds a coroutine context as a context parameter) should be written more explicitly. I've read KEEP several times and only then understood the point.

[nikitabobko]

thought I think that the main point [...] should be written more explicitly

The main point is written right after the Goals in The proposal section:

The proposal is to treat all suspend functions as if their bodies were implicitly enclosed within context(getContinuation_compiler_intrinsic().context) { /* the rest of the body... */ } stdlib function:

I don't understand how it could be made more explicit

---

that suspend function modifier adds a coroutine context as a context parameter

<pedantic>Incorrect</pedantic>. suspend function modifier encloses the function body within context(getContinuation_compiler_intrinsic().context) { /* the rest of the body... */ }

The subtle differences between the approaches are described in this section: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0443-suspend-CoroutineContext-context-parameter.md#discarded-alternative-treat-all-suspend-functions-as-if-they-had-an-implicit-coroutinecontext-context-parameter

[SPC-code]

Indeed, it is written, but I had to read several times to understand the point. Maybe adding a straightforward example where context parameter is used inside suspend function would help. There are more complicated examples near the end of KEEP, but I had to read it to the end to understand.

[SPC-code]

suspend fun computation(){
    foo() // Green code
}

context(_: CoroutineContext)
fun foo() {}

This way I understand what happens. The way it is written in KEEP, the thing that compiler does mixes with what user has to do.

[nikitabobko]

Should be fixed in the main

[IRus]

Looking at this example:

suspendVsContext() // Should resolve to #3 according to the current proposal
regularVsContext() // Should resolve to #4 according to the current proposal

I'm not sure I'm following why in case of suspendVsContext context function takes precedence over suspend.
With regular functions it's clear that context function should take precedence, since it's more specific signature.

But in case of suspend vs context it's not so clear, since suspend always called from suspend functions and context will be always presented there. As developer I'll rather want OVERLOAD_RESOLUTION_AMBIGUITY, since it's equally likely that I want to call suspend function from suspend context (I think this case even more likely) or regular function.

Even if such behavior more logical, I think it's less desired and just prohibit such shadowing maybe better solution

[nikitabobko]

Yes, it's not desired and I dislike it as well. As stated in the KEEP, I hope that we will change the resolution rules for context parameters in this place:

This place looks suspicious. The overload resolution ambiguity would be a more natural behavior. This is a potential subject to change in the context parameters proposal.

[sam-coopercode]

I think the proposal makes a lot of sense, but I'm concerned that the new context parameter could introduce some confusion because it looks very similar to (but behaves differently from) a coroutine scope.

• A CoroutineScope is designed to be used as an implicit receiver, providing access to coroutineContext, launch, async, etc.
• AFAIU, context parameters have similar design goals to extension receivers, and are likely to replace extension receivers in some APIs going forward.

In fact, I can see a world where we might want to replace coroutine scopes with context parameters—which would, I think, run into conflict with this proposal.

If coroutine scopes and context parameters are just two different ways to bring coroutine context into scope, why do I say that the two things conflict? Because the proposed context parameter provides access to the current coroutine context, which is typically not what we want from a coroutine scope. Inside a suspending function, if we want a coroutine scope, we want it to use not the current context but a new child context, e.g. via the coroutineScope { … } builder. (That ensures the suspending function will complete all its work, including any coroutines it launched, before it returns. This is closely related to the convention whereby a function should either have the suspend modifier or a CoroutineScope receiver, but never both).

Here's my concern:

• If coroutine scope and context parameters are both ways to bring coroutine context in some sense "into scope", people could be confused about which coroutine context is which—since the two will not (and should not) always be the same.
• Adding this context parameter could make it difficult to change the coroutine scope API to use context parameters in future.
• Making it easier to access the current coroutine context from inside a suspending function could make it easier to (intentionally or unintentionally) leak coroutines from a suspending function, or to call other functions that violate structured concurrency.

With all that said, I do think it would be great to have an easier way to call ensureActive() without needing the suspend modifier!

[IRus]

If I understand your concerns correctly, looking at this code, results wouldn't be expected, correct?:

import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.ensureActive
import kotlin.contracts.ExperimentalContracts
import kotlin.coroutines.CoroutineContext
import kotlin.coroutines.coroutineContext

// emulate new behavior 
@OptIn(ExperimentalContracts::class)
suspend inline fun <R> intrinsicCoroutineContext(block: context(CoroutineContext) () -> R): R {
    kotlin.contracts.contract {
        callsInPlace(block, kotlin.contracts.InvocationKind.EXACTLY_ONCE)
    }
    return block(coroutineContext)
}

// just to play with new context
context(context: CoroutineContext)
inline val proposedCoroutineContext: CoroutineContext get() = context

suspend fun main() {
    emulateProposal()
}

suspend fun emulateProposal() = intrinsicCoroutineContext {
    coroutineScope {
        println("Scope context: $coroutineContext")
        println("42 is prime: ${42.isPrime()}")
    }
}

context(context: CoroutineContext)
fun Int.isPrime(): Boolean {
    println("isPrime called from $context")
    if (this < 2) return false
    for (cur in 2L..Long.MAX_VALUE) {
        context.ensureActive()
        if (cur * cur > this) break
        if (this % cur == 0L) return false
    }
    return true
}

Result is:

Scope context: ScopeCoroutine{Active}@42110406
isPrime called from EmptyCoroutineContext
42 is prime: false

Expected result:

Scope context: ScopeCoroutine{Active}@42110406
isPrime called from ScopeCoroutine{Active}@42110406
42 is prime: false

[sam-coopercode]

Interesting question… since the lambda body of the coroutineScope { … } function is itself a suspending function, I assume that under the new proposal it would get its own copy of the context parameter, which would replace the one from the outer function. So it's possible the example you shared would actually work correctly.

I don't have a specific example where this proposal would cause an unexpected result when trying to access the coroutine context or launch a new coroutine. I guess my concern is more of a theoretical one about the potential for confusion between two things that look similar but have different purposes and could evolve in diverging ways.

[IRus]

Ah, I see, so since coroutineScope indeed accepts suspend lambda it would have own context parameter, so example would work correctly:

suspend fun emulateProposal() = intrinsicCoroutineContext {
    coroutineScope {
        intrinsicCoroutineContext {
            println("Scope context: $coroutineContext")
            println("42 is prime: ${42.isPrime()}")
        }
    }
}

Scope context: ScopeCoroutine{Active}@42110406
isPrime called from ScopeCoroutine{Active}@42110406
42 is prime: false