Was there a plan to remove Validated in favor of E...

# arrow

[rednifre]

Was there a plan to remove Validated in favor of Either, or did I just imagine this? Or replacing Try with Either? Something like that?

[simon.vergauwen]

No, you're not imagining that 😄 Try was removed in prior to 1.0.0 3-4 years ago.

The functionality is Validated or rather accumulating errors with zip or travers will be exposed through a DSL. zipOrAccumulate and mapOrAccumulate respectively.
And some APIs will also become available on Either.

This is soon-ish, hopefully this month released as 1.2.0-RC and in that release Validated will be deprecated. Later this year (TBD) in Arrow 2.0 the deprecated stuff will be removed. We want to offer a long migration grace period, and (hopefully*) offer some automated migration using OpenRewrite before we actually remove things and release 2.0.

*: Kotlin support in OpenRewrite is currently experimental, and I am working with them to support/fix the issues we need to offer this.

[simon.vergauwen]

You can already test this APIs on the latest `alpha`'s on Maven Central, but some of the APIs are still a little bit in flux based on feedback and testing them in projects.

[rednifre]

Neat! Is there a list of Arrow things I should and shouldn’t use right now so that the transition to 2.0 will be smooth?

[simon.vergauwen]

Hmm, not really 😅
If you're currently on `1.1.5`:
• traverse and Validated will be deprecated later this month accompanied by ReplaceWith. So should be easy to switch to the new API.
• Everything in Either that will be deprecated is already deprecated in 1.1.5, so just avoid deprecated methods.
• The DSL will soon switch package, but will be source-compatible
So the biggest change is traverse / Validated but migration should be relatively easy. Otherwise you can also use 1.1.6-alpha.51. The code is stable, and `zipOrAccumulate`/`mapOrAccumulate` are unlikely to change in API.

Transition to 2.0.0 should be smooth no matter what you use. Providing good tooling using ReplaceWith (from Kotlin itself), or OpenRewrite is a big priority for us. 2.0.0 is mostly cleaning up a bunch of legacy things, and ironing out some kinks in the APIs like Kotlin unfriendly names or signatures. We haven't removed any features, or functionality. It seems like a bigger change then it is, but since we will break binary compatibility we should bump major versions since we follow semantic versioning

[simon.vergauwen]

Personally, I would just use 1.1.6-alpha.51 and avoid deprecated APIs.

[simon.vergauwen]

Since we're so late in the process, and so close to 1.2.0-RC it's very unlikely you'll encounter any issues. It's effectively already an RC without officially being named as such, since we're still making some small changes here and there to finalise all the changes.

[Pavel]

@simon.vergauwen Does this mean that API for 2.0 will be shaped in 1.2 and not change much between 1.2 and 2.0? Are you waiting for context receivers to release 2.0? Because that might not happen this year 😞

[simon.vergauwen]

Hey @Pavel,
The 2.0 API is indeed being shaped (or rather back-ported) to 1.2. This is because we want to offer a long timeframe where users can use 2.0 APIs, provide feedback, and have plenty of time to get rid of @Deprecated code before doing any breaking changes. We also need to update our own systems etc, so I am also working together with OpenRewrite to automate the process of getting rid of @Deprecated.

So the only difference between 1.2 and 2.0 will be the decrease in binary size (removing all @Deprecated code). There is not really a need to wait for context receivers, since in 99,99% the cases that would just change A.() -> B to context(A) () -> B to avoid scope pollution.

I've been thinking if we should wait for Kotlin 2.0, but I think we'll await the announcements next month @ KotlinConf to make that decision to see what'll actually change / break.