Why is this syntax for multiple context receivers:...
# language-evolution
d
Why is this syntax for multiple context receivers:
Copy code
context(Logging, Application)
fun hello() {
  <http://logger.info|logger.info>("Hello " + applicationName)
}
Prefered over this:
Copy code
fun (Logging, Application).hello() {
  <http://logger.info|logger.info>("Hello " + applicationName)
}
In my opinion the second one is more readable and makes intuitively more sense when you know how to do one context receiver just put braces around. I'm sure that considerations have been made here, but I can't imagine one real advatage of the first code example over the second one
👎 2
👍🏾 1
👍 2
👎🏾 1
d
Syntax you propose blocks potential introducing of tuples into the language
K 1
Also in your syntax extension receiver and context receivers are mixed, but they are two different entities which have different rules of call resolution
d
Ah ok, makes sense. I haven't tested it yet, but can you mix context and extension receivers:
Copy code
context(Application)
fun Logging.hello() {
  <http://logger.info|logger.info>("Hello " + applicationName)
}
d
Also your syntax is not suitable for context on classes, so there would be two different syntax (one for members, one for classes), which is inconsistent
d
Makes sense, thank you
b
Just re-phrasing what Dmitry said about them being different entities, since it took a bit for it to click with me when first reading the context receiver proposal. But basically the're different kinds of receivers
Copy code
context(MyContext)
fun useMyContext() {}
This function can't be used like an extension receiver:
Copy code
val myContext: MyContext

// Won't compile, since `myContext` is being used as an extension receiver, but a context was expected
myContext.useMyContext()
I'm pretty sure you can't even do this:
Copy code
with (myContext) {
    this.useMyContext()
}
The main distinction is that a function can be called within multiple scopes/contexts, but, you can't really
.call()
a function on multiple variables at once. So having
Logging
and
Application
both as "extension" receivers doesn't make sense. (though it could in the future with tuples)
e
I also dislike receivers on a different line Personally, I'd like a
contextalias
similar to
typealias