Add `MergeSources` to AsyncResultCE so we can use `and!` safely

[64J0]

Is your feature request related to a problem? Please describe.

When using this script:

#r "nuget: FsToolkit.ErrorHandling, 4.18.0"

open FsToolkit.ErrorHandling

let ok1 () =
    printfn "Called ok1"
    Ok 1 |> async.Return

let err1 () : Async<Result<unit, string>> =
    printfn "Called err1"
    Error "1" |> async.Return

let ok2 () =
    printfn "Called ok2"
    Ok 2

let err2 () : Result<unit, string> =
    printfn "Called err2"
    Error "2"

let workflow1 () =
    asyncResult {
        let! _ = ok1 ()
        and! _ = err1 ()
        and! _ = ok2 ()
        and! _ = err2 ()

        printfn "workflow1 finished"
    }

let workflow2 () =
    asyncResult {
        let! _ = ok1 ()
        let! _ = err1 ()
        let! _ = ok2 ()
        let! _ = err2 ()

        printfn "workflow2 finished"
    }

async {
    printfn "Using let! and and! ...\n"
    let! res1 = workflow1 ()
    printfn "%A" res1

    printfn "\n\nUsing only let! ...\n"
    let! res2 = workflow2 ()
    printfn "%A" res2

    return ()
}
|> Async.RunSynchronously

I noticed that all the values are evaluated inside the asyncResult CE with no short-circuit being applied (what I mean by short-circuit is the mechanism that returns immediately after a Result.Error appears in the case of the asyncResult CE).

After executing this script I get this log at the console:

Using let! and and! ...

Called ok1
Called err1
Called ok2
Called err2
Error "1"


Using only let! ...

Called ok1
Called err1
Error "1"

Describe the solution you'd like

It would be great to have the short-circuit when using the and! for AsyncResult CE.

Describe alternatives you've considered

Additional context

• Microsoft docs tell us to use and! for performance reasons -> https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#and

[TheAngryByrd]

and! has already been removed from AsyncResult in v5 #261 because it didn't really make sense. It didn't execute in parallel nor did it accumulate.

That being said, and! isn't a short circuit mechanism. If you want to short-circuit, you have to use subsequent let!.

If you want accumulation, you'll want to use asyncValidation.

If you want parallel execution, there is no builder currently but I would accept a PR based on ParallelAsync

[64J0]

Indeed, this and! behavior that I had in mind is exactly what let! is currently doing. Btw, thanks for the reply and the links!

[njlr]

If you want parallel execution, there is no builder currently but I would accept a PR based on ParallelAsync

Can send a PR for this with a bit of guidance.

• Should the implementation live in here or IcedTasks?
• What should the builder(s) be called?

Thanks!

[TheAngryByrd]

Should the implementation live in here or IcedTasks?

Here in FsToolkit

What should the builder(s) be called?

Since I think there's two scenarios that this would want to cover, we'd want to have two different builders

• ParallelAsyncResult
  • Offers parallelism but doesn't accumulate errors.
  • There are some semantics of the finer details here would be tricky though. Do we report the first error from the order in code (like the first let!) or do we report the first one that failed?
  • Similarly, should we attempt cancellation if one has reported a failure but another is still in flight?
• ParallelAsyncValidation
  • Offers parallelism and accumulates errors
  • This one doesn't seem to have the same semantic problems with error reporting because accumulation implies you'd want to wait for all results.

[njlr]

• There are some semantics of the finer details here would be tricky though. Do we report the first error from the order in code (like the first let!) or do we report the first one that failed?

I think it should be the first one to fail since the other should be cancelled (see below).

• Similarly, should we attempt cancellation if one has reported a failure but another is still in flight?

I support cancellation since if you don't want cancellation you can use the validation variant.