Simon Vergauwen

I guess this is still applicable to `optics-reflect`, right @JorgeCastilloPrz? That is the only library in Arrow that relies on reflection, so should it require an `arrow.optics.*` configuration in proguard/R8....

This should be solved with the new Raise based DSL, and for Raise errors can also be _traced_ with the new [traced](https://apidocs.arrow-kt.io/arrow-core/arrow.core.raise/traced.html?query=inline%20fun%20%3CError,%20A%3E%20Raise%3CError%3E.traced(block:%20Raise%3CError%3E.()%20-%3E%20A,%20trace:%20(trace:%20Trace,%20error:%20Error)%20-%3E%20Unit):%20A) API.

Hey @MarkMarkyMarkus, Thank you so much for the contribution! And congrats on your first contribution being merged 🙌 🥳 Sorry it took so very long to get this picked back...

This PR proposes following changes: # Integrate `Validated` into `Either` Based on some discussion on KotlinLang, and quite some confusion why there is both `Validated` and `Either` especially amongst beginners...

Hey @pakoito, Thanks for sharing, great to hear that you've also experienced this and looked for a middle ground in 1.x.x 😁 > mapAccumulating -> mapAccumulatingLeft I felt `mapAccumulating` was...

> For mapping: mapOrAccumulate, mapOrRaiseFirst `mapOrRaiseFirst` do you mean short-circuit behaviour? That is just `map`. ```kotlin object Error fun process(i: Int): Either = i.right() fun Raise.process2(i: Int): Int = i...

I am unsure we can rely on the kites extension for Arrow in the 2.x.x since they're build using 1.x.x, and both versions are not compatible.. 🤔

@serras if you want I can decouple them in 1.x.x, and we can merge that to 2.x.x

> Wouldn’t we have the same problem? We cannot depend on the test module until there’s a 2.x-compatible version, right? I mean stop relying on the test-module entirely. So decouple...

Thanks @serras 🙌 That was a big chunk.