Conversation
|
Thanks for pinging me on this! I'll have a look really soon! I had some ideas in a repo called arrow-context, but that's out-of-date now since it was using context receivers |
Kover Report
|
tKe
left a comment
There was a problem hiding this comment.
🙌 Looks like a great first step towards supporting context-parameters.
Is it worth taking the same approach with another module for fx contextual?
Worth adding in some bridges for some of the RaiseAccumulate methods? It's not currently possible to use:
context(_: RaiseAccumulate<String>)
private fun example() {
val a by accumulating { }
}(although this would require making the getValue operator available outside of RaiseAccumulate)
|
Okay... I need to refactor my project 😂 |
It seems that context parameters will not force pre-release binaries. |
119a9d8 to
2cf166f
Compare
|
Since context parameters will not poison the binary, maybe we should just include these functions in |
|
Yes, sounds good to me! |
|
Could it be that in your contextual bridge function you did not put all of the contract definition as done by the Raise member functions? I.e.: |
|
Closed in favor of #3646 |
The time has finally come to provide
Raisewith context parameters! Note that if we publish this library, users still need to use-Xskip-prerelease-checkin their build file.This PR is the start of the conversation of which functions we should expose using context-parameters-style. In this case I've decided to go with the following idea: minimize the amount of additional functions, while allowing people to freely define their functions as:
More concretely, this implies:
either,option, etcetera) with contextual functions. The current functions work still OK with contextual parameters, since the receiver is part of context parameter resolution,bindAllandmapOrAccumulatewith the iterable/sequence/map being a receiver.