So, context parameters, nee receivers. I see that the compiler now says Experimental context receive...

# language-proposals

[dmcg]

So, context parameters, nee receivers. I see that the compiler now says Experimental context receivers are deprecated and will be superseded by context parameters. Please don’t use context receivers. You can either pass parameters explicitly or use members with extensions. Passing parameters explicitly I understand, but what exactly is meant by use members with extensions? I would like if possible to maintain at least some of the structure that my existing context receivers gave in the interregnum during which neither context receivers nor context parameters will be supported

[dmcg]

Also, please do tell me if there is another Slack channel more appropriate for this question

[Alejandro Serrano.Mena]

that means that instead of context(A) fun foo(..) you can try to use fun A.foo(..)

[okarm]

I think that specifically calls out the ability to replace up to 2-arity context using an extension that is a member of a class

Something like this:

instead of
context(A, B) fun foo()

use
Class A {
    fun B.foo() {}
}

[dmcg]

Yeah, so the solutions that we used as examples of why we needed context parameters! It’s, erm, disappointing that we are either going to have to skip a Kotlin version and then migrate, or remove code and then put it back in, but the bleeding edge draws blood.

[Ruckus]

To answer your other question, #CQ3GFJTU1 or even #C0B8MA7FA would be a better place to ask. This channel is specifically for proposing changes to the language:
> All discussion in this channel should begin with a use-case or proposal instead of a question. #CQ3GFJTU1 can be used for other discussions and for questions.