as a follow-up to the above: any idea what `arrow`...

# arrow

[Chris Lee]

as a follow-up to the above: any idea what arrow is doing wrt context receivers, as that is part of the 1.2.x / 2.x APIs? Please don’t make us go back to .bind(), code is so much cleaner with context receivers…

[CLOVIS]

Stable versions of Arrow aren't using context receivers internally, so the team doesn't need to do anything, and Arrow doesn't need to change due to this announcement.

The decision is on you:
• Either you continue using context receivers (and you will have to skip a few Kotlin versions until context parameters are available)
• Or you rewrite all your code using context receivers to single receivers…
For those of us who only do KMP, the choice is easy, we never had context receivers in the first place 😅

[Norbi]

who only do KMP

I use context receivers in both JVM and JS projects (and in Common code as well).
I guess it is supported in Native, too...

[CLOVIS]

Hmm context receivers never made it to JS to my knowledge, they (are) were only JVM-only

[Norbi]

I don't remember the exact Kotlin version but 1.9.20 surely contained the support for multiplatform context receivers.

[CLOVIS]

Not that I know of... Do you have some open source code that does? I've never seen any

[Norbi]

I don't have any where you can see it explicitly.

But here is an example from my in-house remoting implementation: https://github.com/kotlinw/kotlinw/blob/2a845d35db639d447b05b52e697b4d95ee2dc5fb/k[…]n/kotlin/kotlinw/remoting/processor/test/ExampleRaiseService.kt
It is in commonMain and the project has JVM, JS and linuxX64 targets.
(My remoting implementation has support for transporting raised errors between nodes, so it supports raising/handling typed errors occured during remote operations.)
(Sorry, the project is not high quality, it is just for fun and "always experimental" because I don't really have time to work on it 😞)

But in my private projects I found explicit usage of context receivers in JS-only Compose HTML code (in jsMain, extract):

import org.jetbrains.compose.web.css.SelectorsScope
import org.jetbrains.compose.web.css.selectors.CSSSelector

context(SelectorsScope)
infix fun CSSSelector.child(selector: CSSSelector): CSSSelector = child(this, selector)

[Norbi]

But I use context receivers a lot, for example to enforce transactional context in JPA code at compilation-time, like:

interface GenericEntityRepository<E, ID : Serializable> {

    context(TransactionContext, JpaSessionContext) // JPA operation, transaction is mandatory
    fun persist(entity: E): E

    ...

    context(JpaSessionContext) // JPA operation, transaction is optional
    fun findOrNull(id: ID): E?

Of course it is just an idea, and experimental as always 🙂, but it seems to work quite well...