Moving the discussion from this thread <https://ko...

# arrow-contributors

[Sam Pengilly]

Moving the discussion from this thread https://kotlinlang.slack.com/archives/C5UPMM0A0/p1690430479357639 over here

[Sam Pengilly]

I'm having a bit of a look this morning at my typical use case to see whether the discussed getOrAccumulate function would help. I think there's a handful of functions that will need to be added, not just one

[Sam Pengilly]

This is a typical example of how I'm parsing remote data using Either. Rather than short circuiting with GraphQL errors like we currently do. We'd like to change this to an Ior to track non-critical errors alongside the actual parsed data.

ensureNoErrors is a custom DSL function that raises if the error list is not null and not empty. We'd like to change this to a construct that accumulates errors rather than short-circuiting. It doesn't seem like there is a way within IorRaise to simply append/combine an error (since combine is internal).

We also filter out any list items that fail to parse with mapNotNull { it.getOrNull() }, it would be good to filter them out but also accumulate the errors.

[Sam Pengilly]

I'm not sure that Either<Error, A>.getOrAccumulate() inside IorRaise will be enough.

There's currently an Either<A, B>.toIor() function that will never produce an Ior.Both case. I wonder if an alternative like Either<A, B>.recoverToIor(recover: (A) -> B) function might help there?

[Sam Pengilly]

With that the use case for filtering the list of parsing results might start to look like:

.mapNotNull { it.recoverToIor { null }.bind() }

[Sam Pengilly]

Not sure if this is the right direction though. Would be good to get some input on all of this

[Sam Pengilly]

Would it make sense to open up combine() in IorRaise to be called inside the ior {} builder?