The main difference is that Result is Result<V,E > while the SuccessOrFailure is SuccessOrFailure<V>

For me personally, I think having the E error type first class is important

ah i see, wel lyea hthe KEEP talked about this just being for all kinds of errors and more domain specific error types are still better

there are so many occurrences, there is a clear benefit to be able to capture different

Error

correctly.

anyways back to the previous thing.. do you think you can put out maven artifacts that work for 1.3-M1 ? it has slightly different coroutines and the biggest change is probably that fact that you can get a function reference to coroutines now so i can do

val memoizedCall = ::call.memoize()

I am super noob at Coroutine! Do you wanna a try to open a PR for it?

well i really just took the existing coroutine library and updated the dependency to use the mature coroutines in 1.3

downside to that is well.. dependency on EAP .. other libraries have both and support them in parallel

i am also super new and noobish wih coroutines

but how its implemented in fuel-coroutines seems good

due to the dependency on 1.3-M2 you probably also need to update other parts of the project.. like eg. kotlin-reflect since oyu cannot mix 1.2 and 1.3 EAP, the compiler will barf at you

i am trying to setup fuel in idea.. i have no idea why gradle complains about a system installed android sdk.. is there some sort of guide for fuel how to set up the android sdk ?

i guess android studio...

@kittinunf i am trying to implement kotlinXSerialization for fuel, i am stuck at handling errors, i am not sure how this code https://github.com/kittinunf/Fuel/blob/dab5c92bca3eff1426bc8348c2ec90ac52b85105/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/Deserializable.kt#L14-L33 or implementations of it would indicate error state, if i just return null it complains that it has to be implemented, if i throw it will not be catched the same tests seem to work in the Jackson test suite.. or jackson does not fail when assigning null to non-nullable fields in kotlin at runtime

I will take a look at your PR 😃

I have just pushed a commit that uses coroutines 0.31 and kotlin 1.3

if you get a second!

I think it might be a good time to release new version for new modules that we added.

for the kotlinx.serialization module ?

btw, i added example section to the readme

I saw thanks

Hey guys, I worked on a small project for building Api’s in kotlin using DSL’s. I used Fuel (klaxon and just a bit of arrow underneath) for the network calls. I haven’t set the project up as a library, but feedback would be much appreciated, Im looking to work on it further, but would love your guys’s feedback. https://github.com/parshav/kalls

wanted to ask whats the state of coroutines and 1.3 migration ? fuel is the only library that is holding me back right now (i think) is there any specific things i could help with ?

It's about to be merged in @Nikky

@Nikky I have a Pr open atm, I don't think that is was merged into the last release

I feel we can merge it if i all agree?

i am working on cleaning up the kts scripts, dropping the

buildscript

block in favor of

plugins

works good so far, now i just need to refactor all the plugin ids used all over the place in constants

running tests and then opening a PR