With 2.1.20 out is it worth adding a module for co...

# arrow-contributors

[phldavies]

With 2.1.20 out is it worth adding a module for context parameter bridge methods for simulating receivers to ease the transition?

[Alejandro Serrano.Mena]

That's the plan. However, I would prefer to defer release until 2.2.0, when context parameters are experimental-but-more-stable; the current implementation is still in flux a lot

[phldavies]

how much is the syntax likely to be impacted before 2.2.0? I would assume we could mark any such bridging methods as inline and only attempt for source-compatibility

[Alejandro Serrano.Mena]

likely nothing, the syntax is quite fixed

note however than marking something as inlin does not mean it does not appear in the ABI (it still needed for some purposes like creating callable references)

[phldavies]

I wasn't so worried about the ABI of the arrow module providing the bridges, but avoiding any consumers compiled artifacts from being coupled to the bridges at runtime for normal usage. Obviously any references to those inline bridges would break that. That said, callable references with context parameters aren't supported are they?

i.e.

context(raise: Raise<Err>)
inline fun <Err> raise(r: Err): Nothing = raise.raise(r)

[Alejandro Serrano.Mena]

there are two separate things:
• if we mark them as inline , they will "disappear" in all usages in which we call them
• however, they are still part of the ABI of arrow-core

[phldavies]

however, they are still part of the ABI of arrow-core

This is why I was thinking of a separate module (for now) for these bridges - arrow-core-ctxparam-support or something suitably named - to avoid impacting arrow-core ABI while providing bridges for those opting into context-parameters early

[Erik Dreyer]

Is there a similar top line bridge function we could define that would also allow Either.bind() to work? It used to work with context receivers, but I'm struggling to find the right bridge function to get the Either.bind() extension function working with context params

[Alejandro Serrano.Mena]

yes, in such a module every function from Raise would be re-exported as bridge function; bind is especially painful to use otherwise

[phldavies]

@Suppress("NOTHING_TO_INLINE")
context(r: Raise<Err>)
inline fun <Err, A> Either<Err, A>.bind(): A = with(r) { bind() }

this should work (completely untested) as a bridge for now

[Erik Dreyer]

ahh, thank you. I'm just playing around with this for now to get familiarity, but looking forward to migrating a project from context receivers to ctx params.