I would suggest to add a link to this http://fsharpforfunandprofit.com/rop/#monads so that people can better understand how it relates to the Either monad

Also I will add more use cases in the documentation

It is very nice of you saying that. I really glad you like it.

:)

Yeah, I will add more content to help reader understand things better.

I compared the source code to that of funktional either and it is clear that you have thought of a lot of use cases and how to integrate, from a style point of view with regular kotlin code

As I wll work with it I will try to give you more feedback

and if you are open to contribution I will also happy to contribute

Yeah. I feel like Either is gearing towards one thing or another, but not both. It is nice but it is too generic. But Result is more practical. It is rather a focus on Success / Failure.

Definitely @yasyd I am very open to any contributions, suggestions, you may have.

Another thing to note is Result is MIT license. You can do anything you'd love to.

similar to Kovenant

Promise<V, Exception>

but a small difference in flatMap vs. unwrap, … and having errors go through the chain to pop out in failure or always lambda. Your chained version doesn’t show the error handling btw, would be good if you translated that into the functional version. Why not sync up with @mplatvoet of Kovenant fame so that Results and Promises could have unified API’s where equivalent?

@apatrida I have just done that. I have a fork of the Result library where I have unified the Api with that of Kovenant

I will publish it spon

nice!

@apatrida: Thanks for useful suggestions. Yeah, I would put more into the README so it is much more completed.

Regarding to your observation, yes. It is really similar. I agree with you on that. Somehow, In my opinion,

flatMap

is a little clearer than

bind

. Because it goes similar to the way that

Iterable<T>.flatMap

works ...

@kittinunf: I have just committed my fork where I unify the API with kovenant please take a look

Briefly here are the changes:

renamed dematerialize() to get() to match Kovenant API

renamed get to getAs

Now Error is no more assumed to be always of type exception. I think that there are use cases where this is necessary

kotlin.Result

and our Result has name clashes, unfortunately. The fact that the error that you pasted is pointing to

kotlin.Result

kinda give a tell. Is it possible that you didn’t use our Result? Could you check first whether you are using the “correct” Result class?

Hello, is there any chance publishing JS artifacts for IR backend (or with both option)?

@Robert Jaros would you be up for a PR then? I don't use Kotlin JS myself so I didn't get a chance to work on this as priority

I was about to post a question, but then I realized this channel isn't for

kotlin.Result

but rather for a result library with the same name xD

Sorry to disappoint you 🙏

I frequently get a

ClassCastException

returning

kotlin.Result

from suspending functions, but I can’t accurately figure out the steps to reproduce. it’s always

kotlin.Result cannot be cast to (TheWrappedType)

. Has anyone else seen this or figured out why it happens and how to avoid it? I’m at the stage where I’m considering ditching this API as it’s extremely flakey because of this 😕