Maybe someone is willing to share their experience...

# eap

[maxmello]

Maybe someone is willing to share their experience with context parameters in public here, as well?
Has anyone who was brave enough to already use context receivers in production code / in larger projects already migrated to context parameters ? It is already more robust than context receivers? When I added context receivers to my code, there were many problems with byte code errors, e.g. when I combined context(…) with lots of other keywords (suspend, inline etc.). I worked around those cases. Now I’m unsure if I should already try to migrate to context parameters or wait until Kotlin 2.3.

[maxmello]

For example, this beauty of a function broke when I added context receivers to it 😄

inline fun <reified E : ImmutableResourceEntity<out R>, reified R : ResourceCreatable, reified T : Any> KProperty1<out R, T?>.setDBField(...)

or this one, I was unable to have the statement parameter function be of type suspend context(ReadContext) Transaction.() -> T without byte code errors

suspend fun <T> newReadTransaction(
    transactionIsolation: Int? = null,
    statement: suspend context(Transaction, ReadContext)
    () -> T
)

[altavir]

The problem with context receivers was that it did not work on multiplatform (and had some bugs). Since it is mostly a library feature and most of kotlin-first libraries is multiplatform, previous experience is quite limieted.

[maxmello]

So you would expect the current state of context parameters to work better / more robust already?

[altavir]

If we talk about technical implementation, bugs and IDE support, it already works much better. And it works in multiplatform.

The choice of removing receivers in favor of parameters and specific syntax for it has pros and cons. So far it is mostly fine.

[sindrenm]

We started migrating, but unfortunately have to wait for https://youtrack.jetbrains.com/issue/KT-77713 before proceeding.