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?

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.

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?

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 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 😞

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.