Explicit context arguments

[serras]

This is an issue to discuss explicit context arguments. The current full text of the proposal can be found here.

In this document, we propose an extension to calls to functions with context parameters, so that context arguments can be given explicitly.

[xvbcfj]

This reuses the syntax for normal function calls as if context parameter was not present and it was a regular function parameter. This will be confusing imo.

[serras]

Where do you think the confusion stems from? At the end of the day, context parameters are not that different from optional parameters, except the resolution strategy is slightly more involved.

[xvbcfj]

Extension functions and functions with context parameters both compile to functions with regular arguments. With this proposal you can invoke functions with context parameters using regular function arguments. This first of all seems like exposing internal implementation details + it is different from extension functions.

[kyay10]

I think the mental model of context params vs extension is fundamentally different though. An extension is operating on a specific object. A context parameter is just some param that the function needs. All it takes is one Ctrl-click on the name to discover that it's a context param. Exposing implementation details would be if we treated these functions how we treat lambdas (i.e. you can pass the context parameters positionally first), but this isn't proposing that.

[xvbcfj]

All it takes is one Ctrl-click on the name to discover that it's a context param

Not during code reviews.

I think the mental model of context params vs extension is fundamentally different though.

The mental mental I have considers extensions and context parameters closer to each other than context parameters and regular parameters.

[serras]

The mental mental I have considers extensions and context parameters closer to each other than context parameters and regular parameters

I understand this sentiment, especially if you're coming from using context receivers. However, I think the conceptual model in which context parameters are "just" parameters with a special resolution strategy (so closer to optional parameters) fits much better here.

[sirjoga]

Previously, specifying the name of a contextual parameter meant “I WILL explicitly use this name in the implementation”, otherwise “_” was specified. Now it is proposed to break this convention and, whenever possible, always name contextual parameters for the sole purpose of resolving conflicts if they happen to arise somewhere. Ok, this may be useful, but I would like to hope that as the idea develops, this naming convention will not become strictly mandatory.

[serras]

As time progresses and we understand how context parameters are not context receivers, I feel that using _ for context parameters is becoming a worse idea. At the end of the day, context parameters are just parameters, so it makes sense to use similar disambiguation strategies.

[sirjoga]

I think this is a wider issue

Perhaps even more wider )

Different “internal” and “external” parameter names are just a small special case of separating the function call contract and the implementation contract.

The first useful thing that comes to mind is to use the passed receiver in the extension function not as a receiver, but as a named parameter. This will allow you to avoid exporting all receiver members to the implementation.

[serras]

specifying the name of a contextual parameter meant “I WILL explicitly use this name in the implementation”, otherwise “_” was specified

I don't think the design was explicit about this rule, even though I've heard some developers spell it out as such. As mentioned above, our understanding of how to use context parameters is also evolving (this is the purpose of the "experimental" phase, after all), and we see more and more than simply snapping _ for context parameters is not a good idea in general (if any, because of documentation purposes).

[sirjoga]

I feel that using _ for context parameters is becoming a worse idea

Really charming ((

So DI-usecase is bad idea too, and we need to specify useless (in this case) parameter names mandatory...

[serras]

we need to specify useless (in this case) parameter names mandatory

I think you're taking my words too strongly. In general, you should strive to design an API in which these ambiguities are very rare -- otherwise using a regular parameter fits the bill much better. The purpose of this KEEP is to provide a better "escape hatch" for those cases in which this is not possible, and to provide a way to call a function without too many context surrounding everything.

[sirjoga]

... in addition, previously the name of the contextual parameter was not part of the call contract for the function, and we could write constructions like this:

    interface I {
        context(_: Int)
        fun a() {
        }
    }

    class C : I {
        override context(a: Int) fun a() { println(a) }
    }

Now, as I understand it, it is proposed to consider such constructions invalid?

[serras]

Even thought this was never specified, the compiler will indeed warn you if the name of the context parameter is different from its override, as done with any other parameter.

[sirjoga]

the compiler will indeed warn you if the name of the context parameter is different from its overrid

Currently, no warning is issued — the signatures of the overridden and overriding methods are identical. Once the context parameter name begins to participate in resolution, this example will start to cause problems and, yes, will require warnings to be issued.

I am not arguing against including context parameter names into the call contract; I just think the reason in motivation section is a little strange for this action. In essence, to resolve the conflict mentioned in the motivation, you need to choose what NOT to use from the available context in a specific case. Perhaps it makes sense to support not only context expansion, but also context truncation. This is a slightly broader task, but it may have a wider application.

[IRus]

Perhaps it makes sense to support not only context expansion, but also context truncation

@sirjoga interesting idea, so something like this also might help with example defined in motivation section:

context(theA: A) fun foo() { ... } // 1
context(theB: B) fun foo() { ... } // 2
context(theB: B) fun fooB() { ... }

context(oneA: A, oneB: B) fun bar() {
    restrictedContext(oneA) {
        foo() // calls 1
        fooB() // unresolved
    }
}

[sirjoga]

@IRus maybe not so radically )

I think, DslMarker seems like a highly controversial solution to the problem of removing context/receiver from scope, and will most likely be redesigned over time.

[kyay10]

This finally makes it so that naming context parameters in abstract functions is useful. Nice!
Just checking, how will this interact with @RestrictsSuspension? I hope it works in the expected way:

context(foo: SomeRestrictedScope)
suspend fun bar()
someFunctionWithRestrictedLambda { // this: SomeRestrictedScope
  val other: SomeRestrictedScope = getInstanceFromSomewhereElse()
  bar() // this already works
  bar(foo = this) // should work
  bar(foo = other) // should error
}

[kyay10]

I want to point out that this makes duplicate types in context parameters useable. I believe the decision was made before that subtyping between contexts would be allowed because it'd ultimately error when in call resolution, or both parameters would be fulfilled by the same argument. Now that's no longer the case:

context(a1: A, a2: A)
fun foo() 
// Before, it was never possible to call `foo` with 2 different As, but now you can
val someA = A()
val someOtherA = A()
foo(a1 = someA, a2 = someOtherA)

Note that references to contextual functions are disallowed, so I'm pretty sure you could've never written the code above without reflection, but now you can.
I'm not saying this is a problem; I'm just pointing out that this is now possible...

[pdvrieze]

An interesting observation. It should be noted that this is already true when there is a subtype relationship. As to having two context parameters with the same concrete type, this is something the compiler can warn against. The biggest challenge would be when one (or both) is a generic type variable (or made concrete due to such variable), but in such case the issue is more the ambiguity in the concrete case, and named context parameters could resolve it..

[serras]

Please let's not discuss what has already been discussed at length. There's no way we can provide a general error because of generic type variable, unless we introduce some kind of "non-equality" in the type system (which is a quite a challenge). Thus, our only possibility is to give an ambiguity error at call site.

Please do not take this KEEP as an acceptance of such functions. Why would you create a function of type context(a: Foo, b: Foo) fun ... if the only way to call it is via explicit syntax? You're just introducing regular parameters in a very convoluted way!

[kyay10]

Perhaps I'm misremembering; I seem to recall some point being made that such pathological functions couldn't be used and hence aren't something to worry about. I'm simply pointing out that the situation has changed. It's likely that my memory is incorrect here, so please don't take my comment as a critique or anything, rather it's just an interesting observation that "an error at the call site" won't always happen with pathological functions like the above.

I think there can be less pathological manifestations of this observation when there's type parameters involved and such. They're still not anything to be worried about, but just edge cases that are fun to explore.

[pdvrieze]

Overall a good idea, but I think that handling of "conflicting" overloads where a parameter with the same name is once a context parameter, in another case a regular one can use some more thought (e.g. context(a: A) fun foo() / fun foo(a:A)).

First of all, these patterns should be avoided, but in such context (maybe to support compatibility/transition to context parameters), it is not clear why preferring one over the other is legitimate (esp. why would the context one be more specific?).

More importantly is to consider what the rule does to existing code. Existing code that calls foo(a=A()) will call the non-context function, but if this proposal is adopted it would invoke the context function (without exposing this to a developer decision). That is a significant issue in backwards compatibility.

[serras]

Existing code that calls foo(a=A()) will call the non-context function, but if this proposal is adopted it would invoke the context function [...]

This is not strictly true, as this requires adding a new function overload to the mix. And if you add a new function overload in an already-existing codebase, you may start resolving differently.

Note also that in those situations you have ways to call both functions:

• the contextual one using context(a) { foo() }
• the non-contextual one using positional arguments foo(A());

so we're also exploring whether maybe in those situations we should report an ambiguity error instead.

[pdvrieze]

@serras My assumption is that there already were two overloads in the compiler scope in the old code (and yes this requires either different containing files or renaming shenanigans to allow them both to exist). It is even quite possible that the parameter version is a compatibility overload that just forwards to the contextual one.

I agree with the way to call both (although I don't like them as disambiguation - they are less specific than the ambiguous one). The problem is that existing code (for some reason) could be like:

@JvmName("contextFoo")
context(a: A) fun foo() = TODO("Something")

fun foo(a: A) = TODO("Something else")

fun bar() {
    val a = A()
    foo(a=a) // equivalent to `foo(a)` without the proposal, but equivalent to `context(a) { foo() }` in the new one 
}

In other words, the proposal would change the behaviour/resolution of existing code in this exceptional case.

[pdvrieze]

One point to add, the resolution annotations should be able to apply here too, so that a library author could explicitly de-prioritise one candidate from resolution.

[kyay10]

Context parameters are experimental. Changes in overload resolution are thus not a big deal. In fact, a lot of Kotlin features, when introduced, changed overload resolution. Most recently I think Subtyping Reconstruction changes overload resolution, and it's okay.

The workaround for the library author is as simple as choosing a different name. I don't think the resolution annotations make much sense here necessarily, but it doesn't hurt to extend them to this I guess.

[pdvrieze]

@kyay10 Good point about them being experimental. The remaining point is still which of the two should be preferred, if any. I'd still prefer for them being flagged as ambiguous (unless an annotation resolves it). Note that I would still find a function without defaults more specific than one with defaults (not given a value)

[serras]

Based on the new availability of explicit context arguments, we have decided to update the way "most specific candidate selection" treats context parameters, as described in this commit. In short:

• the previous rule of "prefer overload with some context parameters to one without" no longer applies,
• if a context argument is given explicitly, we consider its declaration-site type for choosing the overload (as we do with any other argument).