Opinion on stdlib `kotlin.Result<T>` in kotlin 1.3

Kotlin 1.3 introduces a new built in type called Result<T> (docs) in the standard library (stdlib) and in the kotlin package.

Do you have an opinion on it? It seems to have taken a lot of inspiration from this library, but with one big difference: It doesn’t have an equivalent to flatMap for operations that return a new Result<T>. It also doesn’t place any constraints on errors, which are typed as Throwable.

The immediate inconvenience after upgrading my project to kotlin 1.3 is that I now need to explicitly add the import to use com.github.kittinunf.result.Result.

The KEEP can be seen here: https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md

[kittinunf]

Yes, it is too unfortunate that had the standard lib Result (which I will call as std Result as opposed to just regular Result in this repo) covered most of the functionalities, I would have deprecated this library in favor of the standard one.

The difference mainly

1. std Result has some limitations, unable to use as a return type is a huge bummer.
2. Have a constraint type Error is a good thing. For me personally, it is a huge difference between Result<Data, IOException> vs Result<Data, NetworkException>. With the std Result it would end up as Result<Data> and you have to cast to the right Exception that you wanna use later down the road which is a bummer.

With those 2 points, it looks like (fortunately or unfortunately) this Result has a reason to stay in the community I guess. 😄 😅

It is unfortunate that as of this version, the name is clashing and I am not keen to change the name of this library either. I couldn’t think of a better to deal with this though. If you have some ideas, I am all ears 👂 👂

[ragnese]

I would strongly suggest renaming to “Try”, following in the footsteps of Scala and the kotlin Arrow library.

I agree that this library is much more useful than the standard Result monad.