Update Either.zipOrAccumulate

[nomisRev]

New Description

Note: Everything mentioned here is open for discussion, so please provide all feedback.

We've introduce earlier Either.zipOrAccumulate for combine + Either, Either & EitherNel. This however doesn't allow intermixing of Either & EitherNel in the same function and thus requires manual lifting in some cases. Defining all different combination would be almost impossible ((9^2)*2 = 162 methods). i.e.

Either.zipOrAccumulate(String::plus, "error".leftNel(), 1.right()) { x: Int, y: Int -> x + y }
Either.zipOrAccumulate(String::plus, "error".leftNel(), 1.right()) { x: Int, y: Int -> x + y }
Either.zipOrAccumulate(1.right(), "error".leftNel()) { x: Int, y: Int -> x + y }
Either.zipOrAccumulate("error".leftNel(), 1.right()) { x: Int, y: Int -> x + y }

Without adding the 162 methods users need to manually do, although this is the same as before with Validated.

Either.zipOrAccumulate(String::plus, "error".leftNel(), 1.right().toEitherNel()) { x: Int, y: Int -> x + y }
Either.zipOrAccumulate(String::plus, "error".leftNel(), 1.right().toEitherNel()) { x: Int, y: Int -> x + y }
Either.zipOrAccumulate(1.right().toEitherNel(), "error".leftNel()) { x: Int, y: Int -> x + y }
Either.zipOrAccumulate("error".leftNel(), 1.right().toEitherNel()) { x: Int, y: Int -> x + y }

To solve this problem Arrow introduced a DSL zipOrAccumulate API that allows binding both Raise<E> and Raise<NonEmptyList<E>> and thus also Either<E, ?> and EitherNel<E, ?> This serves as a replacement for the accumulate error pattern of Validated<E, ?> and ValidatedNel<E, ?>.

However this doesn't allow to pass Either values, and thus the API for Either is the same as Raise with the exception of it getting nesting in the DSL.

either {
  zipOrAccumulate({ "error".leftNel().bindNel() }, { 1.right().bind() }) { x: Int, y: Int -> x + y }
} shouldBe Either.zipOrAccumulate({ "error".leftNel().bindNel() }, { 1.right().bind() }) { x: Int, y: Int -> x + y }

So this brings the question:

• Do we want to introduce this DSL based API for Either.Companion
• Do we want to force users to manually wrap in either { }
• Or do we want to stick to the current status-quo requiring toEitherNel() and work value based? (Note that the current value based implementation could still be derived from the DSL one).

Side note: zip deprecation

Arrow is deprecating Either.zip(fa, fb, f) in favour of either { f(fa.bind(), fb.bind()) } since it doesn't suffer from the arity-n problem, and offers the exact same behavior. Since either is now inline fun in 1.2.0 and thus works with-or-without suspend it can be used as a drop-in replacement. This has happened so far for Either, Option and still needs to happen for Ior, Result & Nullable.😅 Unless we're coming back from that (?), the deprecation has not been released yet.

Old description

This PR updates Either.zipOrAccumulate but sadly since we don't have context receivers yet, and have to emulate through RaiseAccumulate it breaks inference / BuilderInference in a worse way than the PR that started this effort, #2952. This PR the signature with parZipOrAccumulate.

We can of-course put off this change, and keep the current signatures until we have context-receivers. The migration path for it is relatively simple, and it will be easily to automate. With ReplaceWith (or OpenRewrite).

More details below:

If we put @BuilderInference on the method, instead of the individual functions we get following error:

Some related YouTrack tickets related to the IDEA message:

• https://youtrack.jetbrains.com/issue/KT-53797
• https://youtrack.jetbrains.com/issue/KT-53740/Builder-inference-with-multiple-lambdas-leads-to-unsound-type

If we put @BuilderInference we get following error for every lambda that tries to bind EitherNel<E> instead of Either<E> and will require to either specify the type arguments in the function, or specify a return type so E can be inferred from there.

The up sight, with context receivers it looks 🔥 😍

[github-actions]

Kover Report

File	Coverage [53.02%]
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/Either.kt	53.02%

Total Project Coverage	44.08%

[nomisRev]

The issue described above has been fixed for this API by a suggestions made by @Zordid.

[nomisRev]

Closing this PR since we want to keep the Either value based API as it stands in Validated.