Hi, I have just started upgrading Arrow to 1.2.0. The most work was with replacing Validated. Everything works fine. The only thing I’m really concerned with is the removal of “fluent API”. It is suggested to replace, for example,

sequenceEither

method with its “inline” version:

let { l -> either<E, List<A>> { l.bindAll() } }

Instead of a well-understood function name now I have to “parse” the code to find out what it is doing. The worse thing is that the “body” can be formatted in many ways - like

.let { l ->
                    either<FindProfileError, List<ProfileEntry>> {
                        l.bindAll()
                    }
                }

making it even harder to understand the code compared to just one line:

.sequenceEither()

Why do you think that DSL version is better and should be preferred?

Hey Dariusz, There are a couple of reason for doing this. 1. DSL offers what we think is more idiomatic syntax

map vs traverse

. 2. We wanted to reduce duplication in the API, and decrease the API surface (in order to reduce confusion and reduce learning curve) 3. Decrease the binary size We imagine that everyone is already working within the DSL, and in the future context receivers. In those case there is no need for

traverse

or even

bind

. Sadly

ReplaceWith

is not that great. It cannot detect wheter you're already in a DSL, and worse with the

let

call it fails to automatically refactor. The resulting code can actually be simpler that what is described in

ReplaceWith

. That all being said, I guess we might want to add it within the deprecation message. If you prefer fluent API, Quiver is going to add adopt

traverse

&

zip

and potentially some other fluent APIs. I mentioned it in the migration guide, https://arrow-kt.io/learn/quickstart/migration/#either-dsl-effect--effectscope. In the info block. So you can potentially also just ignore these deprecation warnings, and depend on Quiver when finally moving to 2.0. I'm also touching upon this topic in my talk on Thursday on KotlinConf, but I'd more than happy to answer any more questions you have. (Cannot share my slide yet early 😜)

Keeping the API small makes sense. Thank you for keeping old good function in Quiver 🙂.