Michael Bull

This is an interesting idea that I'd accept a PR for. The naming needs work, not a fan of `combineResult` vs `combineResultWithErr` - all Results have the potential for an...

Maybe @Munzey, author of the `binding` story, has some ideas.

Thanks for the report. I'd put off adopting inline value classes for many years until they had been marked as stable, which they were in [Kotlin 1.5](https://kotlinlang.org/docs/whatsnew15.html#inline-classes) as per the...

Retrofit's problem is being tracked alread on their [own pull request](https://github.com/square/retrofit/pull/4018#issuecomment-1973285883) that adds an adapter for the kotlin.Result type. I would anticipate consumers will need to implement their own adapter...

To piggyback on @jods4's comment, you can solve this problem in your own codebase by just declaring the following type: ```typescript type CancellablePromise = Promise & { cancel(): void }...

@jods4 do you have the link to the supporting documentation from whatwg? Would be useful going forward in this discussion, thanks.

Could you paste the example code in which you managed to catch it? It definitely shouldn't leak from the call to `binding{}`/`.bind()`. Generally I would not consider the `BindException` part...

So fundamentally the problem resides in the fact that all calls to `.bind()` in a `binding` expect to throw **exactly one** level up the chain, such that it breaks out...

Hi @CharlieTap. I did some thinking about the use case that you've hit, and I have an idea (to make `runCatching` explicitly handle `BindingException` for you). I was trying this,...

Hi, thanks for your question. I have been pondering on a v2 of the library for a while, as I have some subtle breaking changes that would result in better...