A modern programming language that makes developers happier.

kotlinlang

i just want to  make it sure, is context receiver ready? or when it will exactly? i've searched everywhere and didn't found anything

it is not ready no, and "no target version"
<https://youtrack.jetbrains.com/issue/KT-10468/Context-receivers-multiple-receivers-on-extension-functions-properties>

The context receivers proposal has been dropped and replaced by context parameters: <https://github.com/Kotlin/KEEP/blob/context-parameters/proposals/context-parameters.md>.

Also a KotlinConf talk about it's design status and plans: <https://kotlinconf.com/talks/621119/> (TLDR, prototype will be available after Kotlin 2.2).

is there any reason why? because i found no problem with it, the context parameter is ok but what is the problem with context receiver?

you might get lucky, but I got many compilation problems (expected as it's experimental)

> is there any reason why? because i found no problem with it, the context parameter is ok but what is the problem with context receiver?
Context parameters is very similar to receivers. The main problem with receivers was scope pollution made it difficult to know where functions were coming into scope from.

There is a Q&A in the KEEP about "why drop context receivers" (<https://github.com/Kotlin/KEEP/blob/context-parameters/proposals/context-parameters.md#qa-about-design-decisions>).

ah i see.. the scope polution seems tobe a problem when we have multiple context.
but we can do : `this@ContextName.someFunction()` right? but the case with compiler might be real.

the context parameter give the context a named parameter so we need to call the name to call the function, isn't it so?
in that case, context receiver should be fine to upgrade to context parameter latter right? as long as we don't have duplicated or similar jvm signature for the function in the context. in this case, put some limitation to the implementation should be fine.

or is there another concern?

I made an experiment
```@Immutable
interface SystemLoggerScope {
    fun log(message: String)
}

@Immutable
class SystemLoggerScopeImpl : SystemLoggerScope {
    override fun log(message: String) {
        println("Singularity Log: $message")
    }
}

@Immutable
interface ImpostorScope {
    fun log(message: String)
}

@Immutable
class ImpostorScopeImpl : ImpostorScope {
    override fun log(message: String) {
        println("Imposter Scope $message")
    }
}```
```@Immutable
data class MyBussinessScope(
    val unit: Unit = Unit,
) : SystemLoggerScope by SystemLoggerScopeImpl(),
    ImpostorScope by ImpostorScopeImpl() {

    override fun log(message: String) {
        println("MyBussinessScope $message")
    }

    @Composable
    fun SingularityScopeCompose(
        content: @Composable MyBussinessScope.() -&gt; Unit,
    ) {
        content()
    }
}```
I implement both SystemLoggerScope and ImpostorScope
and the compiler force me to override the method with same signature name.

and there is no compilation error. the app working fine. without needed to refactor.

Sorry about this question goes on in multiplatform channel..