Is there a plan for migrating towards context-para...

# arrow-contributors

[phldavies]

Is there a plan for migrating towards context-parameters (and targeting 2.1.20) in preparation for arrow 2.1? From testing it seems like consumers using context-receivers can still call context-parameters-compiled libraries

[Alejandro Serrano.Mena]

we do not really plan to migrate the current APIs, but definitely improve the API that is provided if you decide to use context parameters

[Alejandro Serrano.Mena]

however, I think it's risky to start now: in 2.1.20 only partial support will be available; 2.2. is the version where context parameters will be finalized (even though first as experimental)

[phldavies]

For some reason I thought there was other usage of context-receivers in arrow, but it seems like it's currently just in the arrow-raise-ktor-server integration (which I've tried to minimise in the "core" APIs).

At the moment they're only added for convenience access from "normal" ktor API usage. (i.e. being able to do call.pathOrRaise(name) from a context in which you have a Raise<Response> or Raise<RequestError> , rather than from within a handleOrRaise or respondOrRaise block which uses a RaiseRoutingContext intersection type as receiver).

It might be worth removing the context receiver usage for now until 2.2 when we can start adding context-parameters cleanly.

[simon.vergauwen]

Another reason to have separate versioning for the Ktor module, no? 😕

In 99,99% of Arrow we're only using single receivers, so changing to context parameters won't change a lot. Except perhaps RaiseAccumulate which would suffer a small binary/source breakage (additional imports).

[phldavies]

At the moment I've removed any context-receiver usage from the ktor module alternative API PR but it would be nice to add it back and avoid the need for a an intersection type. That said, I've also used the intersection scope type to hold a pair of raising delegate providers which makes for (imo) a nice API which I'm not sure would be possible with context-parameters alone.

[simon.vergauwen]

It should be possible, but it would require top-level functions that require imports instead of having them defined as methods on the intersection scope type. I've use intersection scope types a lot, and have nothing against them. Not requiring an import is a good thing.

[phldavies]

It's possible, but would require instantiating the delegate provider at each usage rather than holding a single instance - that said, with a slightly different API we could probably avoid it too.

something like this could work:

context(raise: Raise<String>)
inline val RoutingContext.pathRaising get() = Provider { call.pathParameters[it] ?: raise.raise("missing '$it'") }

context(raise: Raise<String>)
inline fun <reified T: Any> RoutingContext.pathRaising() = Provider { catch({call.pathParameters.getOrFail<T>(it)}, { raise.raise(it.toString()) }) }

context(raise: Raise<String>)
inline fun <T: Any> RoutingContext.pathRaising(crossinline transform: Raise<String>.(String) -> T) = Provider { raise.transform(call.pathParameters[it] ?: raise.raise("missing '$it'")) }

[phldavies]

get("/") {
        either {
            val value by pathRaising
            val intValue: Int by pathRaising()
            val alsoIntValue by pathRaising<Int>()
            val customConvert by pathRaising { it.uppercase() }
        }
    }

[phldavies]

for the ktor module at this point though it's likely simpler and safer to stick with the intersection scope type until context-parameters is closer to GA

[Alejandro Serrano.Mena]

I'll try to set a different versioning scheme for the Ktor modules, so we can iterate more quickly there

[Alejandro Serrano.Mena]

or you think it's better to keep it in a separate repo for the time being?

[phldavies]

if separate versioning within the same repo is doable, it would avoid needing to maintain two distinct build and release setups - although there'd need to be a way for releasing subsets of projects. Potentially composite builds sharing build logic?

[phldavies]

I think suspendapp can likely follow the usual arrow versioning, but I've backported the jvm-deadlock fix to the old repo (https://github.com/arrow-kt/suspendapp/pull/144) if we wanted to push a 0.5.1 out - I intend to keep that PR uptodate with the elected fix from the arrow repo. This would at least allow a faster fix for the jvm bug to be available prior to arrow 2.1 release of suspendapp.
suspendapp-ktor may not need separate versioning as it shouldn't need breaking changes too often

for the new ktor-raise-api, separate versioning for initial release would be good and allow for faster iteration - it could be aligned later or not (so long as it doesn't go above arrow's versioning)

[simon.vergauwen]

I'll take a better look at your PRs tonight @phldavies. Lets try to merge, and push 0.5.1 out 👍 If possible to do split versioning in the same repo that would be great.