Consider adding zipOrAccumulate? about kotlin-result

[michaelbull]

I think the allOk, noneOk, allError, noneError functions can be their own change. I'm happy for you to also continue with zipOrAccumulate as discussed, but it should probably but it's own separate change 👍

[michaelbull]

I'd be willing to accept a PR for this.

Interestingly whilst looking at your example code I have thought up some other collection-related functions we might want.

    return if (
        result1 is Ok &&
        result2 is Ok &&
        result3 is Ok &&
        result4 is Ok &&
        result5 is Ok &&
        result6 is Ok &&
        result7 is Ok &&
        result8 is Ok &&
        result9 is Ok &&
        result10 is Ok
    ) {

Here I would extract out all of these into a list of the results, and then have one function call to check that all the items in the list are Ok. Now that I think about it, we can actually offer these as extension functions, something like Collection<E>.allOk(): Boolean and the same for the Error side.

We might also want to leverage the partition function in the implementation of zipOrAccumulate.

I also wonder if there's an example of this in another functional language, Rust/Scala etc? I feel like if there is, they also might have a more succinct name for such a function.

[YuitoSato]

@michaelbull

Thank you for your thoughts.

Indeed, the standard libraries of Scala, Elm, and Rust do not include a direct counterpart to the zipOrAccumulate function. However, the Scala Cats library provides a similar concept with its Validated type.

Validated allows accumulating multiple errors rather than stopping at the first one, similar to what zipOrAccumulate aims to achieve. Furthermore, Cats provides the mapN function which is somewhat similar to zipOrAccumulate in its behavior.
The mapN function allows you to combine multiple Validated instances and apply a function to their contained values. Here's a simple example of how mapN might be used:

import cats.data.Validated
import cats.implicits._

val v1: Validated[List[String], Int] = Validated.valid(1)
val v2: Validated[List[String], Int] = Validated.valid(2)

val sum: Validated[List[String], Int] = (v1, v2).mapN(_ + _)

In this example, if both v1 and v2 are Valid, the mapN function will add their values together. If either of them is Invalid, mapN will accumulate the errors.

See also: https://typelevel.org/cats/datatypes/validated#an-iteration-with-validated

However, translating this to Kotlin isn't entirely straightforward. While Scala's mapN can leverage the power of Tuples, which allow you to apply a function to a dynamic number of arguments, Kotlin does not have a similar concept.
Considering these points, I think that even though zipOrAccumulate is a somewhat unique feature named in Arrow, it could be seen as a good method design.

If the philosophy of this library is to only implement features that exist in the standard libraries of Scala, Elm, and Rust, I fully respect that. It's always important to maintain consistency with the project's principles and design goals.

I also agree with the introduction of a new allOk method and the use of the partition method for implementation.

[michaelbull]

I think going full-in on a Validated type (or extensions for Result to operate as a Validated type) would probably be a big undertaking. I'm sure it could leverage a lot of the library, just operating in a non-shortcircuiting manner, but would probably take a while to think through properly. This is also something I'm open to.

I'm not intentionally aligning the library with any specific implementation, but looking to existing implementations for inspiration on things like naming and signatures. For example Scala gave us the name for the merge function.

In the short term, I think the allOk & allErrors methods on an Iterable of Result would be great additions to the library if that was something you wanted to tackle before taking on the bigger challenges we've discussed so far.

[YuitoSato]

I understand your thoughts.

So to conclude, should I proceed with the implementation of zipOrAccumulate?
Either way, I plan to implement allOk function.
Or for this PR, should I implement only smaller methods such as allOk, allErrors, etc?

[YuitoSato]

Thank you. I'll try to implement zipOrAccumulate this weekend.