https://kotlinlang.org logo
#arrow
Title
# arrow
r

rednifre

03/14/2023, 6:02 PM
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?
s

simon.vergauwen

03/14/2023, 6:27 PM
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.
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.
r

rednifre

03/14/2023, 6:30 PM
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?
s

simon.vergauwen

03/14/2023, 6:39 PM
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
Personally, I would just use
1.1.6-alpha.51
and avoid deprecated APIs.
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.
p

Pavel

03/15/2023, 8:24 AM
@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 😞
s

simon.vergauwen

03/15/2023, 8:31 AM
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.
8 Views