Raise with context parameters
#3606
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
|
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)
| public typealias Raise<Error> = CoreRaise<Error> | ||
| public typealias SingletonRaise<Error> = CoreSingletonRaise<Error> | ||
| public typealias ResultRaise = CoreResultRaise |
There was a problem hiding this comment.
Is the purpose of these to allow consumers to use only import arrow.core.raise.contextual.* and avoid clashes with arrow.core.raise.*?
|
|
||
| context(raise: Raise<Error>) @RaiseDSL public inline fun <Error, OtherError, A> withError( | ||
| transform: (OtherError) -> Error, | ||
| @BuilderInference block: CoreRaise<OtherError>.() -> A |
There was a problem hiding this comment.
| @BuilderInference block: CoreRaise<OtherError>.() -> A | |
| @BuilderInference block: Raise<OtherError>.() -> A |
better to use the alias for consistency?
| import arrow.core.NonEmptyList | ||
| import arrow.core.raise.* | ||
| import kotlin.experimental.ExperimentalTypeInference | ||
|
|
There was a problem hiding this comment.
Worth also bringing in a typealias for RaiseAccumulate?
|
Okay... I need to refactor my project 😂 |
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.