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

[Niel de Wet]

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

[Kittinun Vantasin]

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

[biberesser]

Yes, the "Result" name conflict is very unfortunate :(
What about renaming this to "Outcome" or just "Out", "Res" or "Ret"?

[Kittinun Vantasin]

I don't feel any of those is quite right ... 😢 😿 😭 😞

[Markus Padourek]

I think "Outcome" imo comes the closes, but I agree Result is much nicer. But imo so far it is not such a big issue as Return from kotlin can not be returned anywhere in user code yet. Once that changes this would probably be an issue but also looking at "Open issues" and especially "Future advancements": https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#future-advancements it looks like we could get a Result type that could fully replace this library.

I really hope that Representing as a sealed class and Parameterizing by the base error type will make it and also the idea of integrating this more into the language sounds very promising.

[Kittinun Vantasin]

@Globegitter I agree! I think as soon as the standard Result type is full-fledged and more mature. I am more than happy to archive this library in favor of the standard one, however, in my personal use case, I still see (in my humble opinion) that there are still shortcomings of using the standard Result.

It kinda justifies the existence of this library for the time being.

[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.

[Shabinder Singh]

If you have some ideas, I am all ears ear ear

How Does EVENT Sound

[Kittinun Vantasin]

As long as Kotlin.Result doesn't support Error type, I assume that Result is still useful and pretty much relevant. I guess we will re-visit this in the future. Close this for now.