Making TaskResult and JobResult libraries

It was requested via twitter to have a TaskResult added to this library. I do believe this would be a good idea, as I also work with task heavy CE workloads and rely on the Result type.

As mentioned in that tweet thread, since the main library wants to be Fable compatible, it would have to be its own separate library. FsToolkit.ErrorHandling.Tasks (something something naming is hard).

In addition to this, I use Hopac quite a bit and have authored the Chessie.Hopac. Similar to the above, it would be its own library FsToolkit.ErrorHandling.Hopac.

I’d be willing to implement both of these libraries if this proposal makes sense.

[TheAngryByrd]

Well some people’s definition of composable implies laziness/cold so you’re dealing with slightly different semantics about how your FuturesObject will behave. But really it’s not less “composable” in the strict sense of the word.

[TheAngryByrd]

@demystifyfp I think keeping it in this repository makes sense. Easier for the dependent libraries to adjust to changes.

@cmeeren Yeah 99% of Tasks are started or “hot” by the time you get a reference to them, so yes they are less composable. Also there’s other downsides like they’re not tail call optimized. The main benefit of using Task over Async is the speed bonus. However it may remain to be seen if having taskResult keeps speed up. I would probably need to make a benchmark for that as well.