Context receivers

[shadrina]

The goal of this proposal is to introduce the support of context-dependent declarations in Kotlin, which was initially requested under the name of "multiple receivers" (KT-10468).

See the proposal text here.

[fvasco]

In the section VM ABI and Java compatibility, the Kotlin code:

context(C1, C2)
fun R.f(p1: P1, p2: P2)

should be equal the Java code

public static final kotlin.Unit f(C1 c1, C2 c2, R r, P1 p1, P2 p2)

Kotlin does not allows void return type, it should be Unit

[altavir]

First of all, let me thank you for a superb (and long-awaited) proposal.

As for the discussion, my primary concern is still the syntax. The proposal mentions that the context(T) construct could be mixed with a function call in the code and it should be treated properly. But what Is more important, it confuses the reader. When I read the code, I can't see clearly that this declaration is attached to the following declaration. I can understand the reasoning behind not using @ (a lot of people have negative emotions about that), but some kind of visible syntax would be nice. Another concern is about using round brackets for types. In kotlin, we always use round brackets for instances, so context(MyContext) reads as a companion object of MyContext, not as the type itself. In Groovy one can use class name instead of class and it brings a lot of confusion sometimes. So I would recommend at least using triangle brackets <> for receiver type to provide clear separation. Like context<MyContext> fun A.doB().

The second point is about the proposal itself. One of the important uses of multiple receivers is the ability to flexibly define behavior intersections. For example, consider this code:

interface A

interface B

context(A,B) fun doSomething()

It could be called as with(a,b){ doSomething}, but in some cases, we also can have:

interface C: A, B

c.doSomething()

This seems to be an idiomatic example of using multiple receivers and I think, it should be covered in the proposal.

[fluidsonic]

Great and thorough proposal with quite a lot of history 🙌

context Syntax

I thought exactly the same as @altavir.
Here it's especially bad: var g: context(Context) Receiver.(Param) -> Unit. Looks like a call within a function body.

context<A, B> is easier to understand and also makes more sense to me.

• You specify types. You don't pass values.
• You have a context that is "parameterized" by A and B.
• No backward compatibility issue as context<A> fun … isn't valid Kotlin code today (afaik) even with a line break.
• Generics like context<Comparator<T>> still aren't an issue.

Could also be context<A & B> instead, having future union types in mind. May cause problems with this@A syntax.
And then later on allows typealias C = A & B with context<C>.

Builders

The use case Creating JSONs with JSONObject and custom DSL is basically a builder DSL.
However in Contexts and coding style you write "Context receivers shall not be used for such builders".
I'd say it depends on the DSL's purpose whether or not a context makes more sense.

[edrd-f]

I think the proposal should go deeper on how context receivers would work with annotations and the suspend modifier. It only says:

Also, suspend and @Composable functions can be retrofitted to work as if they are declared with context(PropertiesScope) modifier and so will pass a set of current context properties via their calls, ensuring interoperability of the corresponding mechanisms.

However, while this retrofitting doesn't happen, how would these functions be declared? There are several options:

1:

@DslMarker context(JsonBuilder) fun String.by(obj: @DslMarker context(JsonBuilder) suspend () -> JsonObject)

2:

context(JsonBuilder) @DslMarker fun String.by(obj: context(JsonBuilder) @DslMarker suspend () -> JsonObject)

3:

context(JsonBuilder) @DslMarker fun String.by(obj: context(JsonBuilder) suspend @DslMarker () -> JsonObject)

4:

context(JsonBuilder) @DslMarker fun String.by(obj: suspend context(JsonBuilder) @DslMarker () -> JsonObject)

[fluidsonic]

@mcpiroman it's already mentioned as a potential future extension.

[fluidsonic]

Another naming-related issue came to mind:

• We have context on the consuming side.
• We have with on the providing side.
• We have withContext in kotlinx-coroutines.

I already found code that accidentally used with instead of withContext.
With the new context soft keyword this will probably get more confusing.

But it may also be an issue with kotlinx-coroutines because withContext is a really generic name.

[edrd-f]

@altavir @fluidsonic - about the suggested <> syntax, the problem is that in context<Comparable<T>>, Comparable is a literal type while T is a generic type, so the semantic meaning of <> gets ambiguous.

[fluidsonic]

@edrd-f

@altavir @fluidsonic - about the suggested <> syntax, the problem is that in context<Comparable<T>>, Comparable is a literal type while T is a generic type, so the semantic meaning of <> gets ambiguous.

I'm not sure I understand you correctly.
It could also be context<Comparable<Int>>. Then Int is a literal type used as an argument to a generic parameter.
The same way context<Foo> has Foo as an argument to a generic parameter that is unnamed and brought into scope in the function (more or less).

We're entering the ambiguous realm anyway. Consider object Foo.
context(Foo) in the fun position is quite different from context(Foo) in regular code.

[altavir]

@edrd-f I don't not see the problem, because we use the receiver type here exactly the same way, we would use it in any other generic case like typeOf<> which takes the type parameter. And in any case, it is better than round brackets since there is no distinction from the function call and, as I already said, association with the companion.

I would prefer something even more distinct, But triangular brackets are better than round ones.

[fvasco]

@edrd-f please consider that context<Comparable<T>>() is already valid Kotlin syntax.

[BenWoodworth]

The main tradeoff we had to make with the proposed syntax is that in case when context is generic, then the use of the generic parameter happens before its declaration, e.g (from Use cases section):

context(Monoid<T>) // T is used
fun <T> List<T>.sum(): T = ...
//  ^^^ T is declared

I might've missed something, but why not put the contexts between <T> and the function's receiver/name? Noise/parsing issues?

fun <T> context(Monoid<T>) List<T>.sum(): T = ...

[mcpiroman]

I might've missed something, but why not put the contexts between <T> and the function's receiver/name? Noise/parsing issues?

fun <T> context(Monoid<T>) List<T>.sum(): T = ...

The problem is, generally, the name matters the most (that's why it's before type) but with such syntax it is shifted near the end of the line. When looking at the function's definition, the context it has is more of a implementation detail, yet, you have to read it first before you get to the name or parameters, which are more important.
Secondly, this aligns more with where annotations are put and this feature for me is closer to annotations.

[b-camphart]

to @mcpiroman's point, maybe the syntax can put the context in the next line, similar to the existing where syntax:

fun <T> List<T>.sum(): T     
context(Monoid<T>) { 

}

It would follow an existing kotlin design pattern and reduce the noise in the main function definition line. Basically, the fact that the function requires additional context is a detail and thus should be below the main part of the definition.

I think this would also help with discoverability on the calling side. Instead of the example sum function simply not existing without all the extra context and thus having to go hunt for the definition, instead it would be treated like an extension function with missing parameters and simply show you a red underline (and tell you what context parameters are missing).

[rnett]

Big +1 for the Scope Properties and Contextual Classes proposals. Scope properties would make my compiler plugins quite a bit nicer (put IrPluginContext in context and a few other things), and contextual classes is exactly what I need for a deep learning library (so that layers can only be defined inside a graph).