Please Refactor to Use Kotlin Result For 1.5+ about kotlin-result

[michaelbull]

I've tried to model this library using the mechanism that Kotlin themselves ended up implementing (an inline class) but concluded that it isn't possible to achieve the majority of what this library achieves. A substantial amount of the extended functions, some of which you've listed, simply don't work when I tried. kotlin.Result is also bounded by Exception, which I am in strong disagreement with, and adopting it would break backwards compatibility for this library.

The Result type in the stdlib was initially implemented purely to accommodate behaviour for the kotlinx-coroutines library, and has only really been alleviated as a return type after many people requested it. I am not convinced much thought has actually been put into making it a first-class citizen within the language when you compare it to implementations provided by stdlib's from other functional languages (Scala, Rust, Haskell, etc).

Kotlin developers themselves have in-fact been on record in admitting that the kotlin.Result type is "half-baked"[1] and is likely to change in future (and therefore I would not be pushing to move a library to extend it). Barely a week after they announced that, their plans changed again and they had decided to allow people to use it as a return type[2] with no mention of increasing its scope, but instead they are exploring checked exceptions in the form of contextual receivers.

[1] https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103/4
[2] https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103/5

However, a lot of the signatures class with Kotlin's (ie, their Result vs your Result) clash, so to use your library I typealias everything (ie, KtResult).

You can configure your IDE to explicitly prevent suggesting importing things like kotlin.Result.

[Munzey]

To add to Michael's comments, I'd recommend a read of the result KEEP doc.
In particular the linked section mentions that the usage pattern for this library (railway oriented programming) is not something they want to pursue as part of the language design.
It doesnt seem to make sense to base this 3rd party library off their class that differs fundamentally

[tom-pratt]

Could you point to some instructions for the IDE setting you mentioned to help with the naming conflict. I tried to google but not quite getting it!

[michaelbull]

https://www.jetbrains.com/help/idea/auto-completing-code.html#exclude