I’ve been playing with different APIs to expose th...

# arrow

[simon.vergauwen]

I’ve been playing with different APIs to expose this in a saner way in terms of cancellation & error tracking. In this case you choose to ignore the result of the Fiber, isn’t it weird that it randomly goes somewhere else then?

In the case below only forkConnected or forkAndForget would leak the exception.

In the case of forkConnected, which is the equivalent of `CoroutineScope.async`` would you expect that the error is send to an asyncErrorHandler as well as stay inside the Fiber for when you join it? So the error would be guaranteed to show up once in the asyncErrorHandler on top of the N times you can join it?

I.e.

/** Returns a fiber that is cancelled when its parent is cancelled **/
fun <A> IO<A>.forkConnected(): IO<Fiber<ForIO, A>>

/** Fork your `IO` in a `Fiber` and consume that fiber in a suspending way. Cancelling the parent will cancel this op.
All errors will be propagated to the result.
 **/
fun <A, B> IO<A>.useFork(f: (Fiber<ForIO, A>) -> IO<B>): IO<B>

/** Current fiber **/
fun IO<A>.forkAndForget(): IO<Fiber<ForIO, A>>