Add `Async.RaceAwait` to FSharp.Core

[Seng-Jik]

I propose we add the these functions to FSharp.Core:

• Async.RaceAwait(a: Async<'a>, b: Async<'b>) : Async<Choice<'a * Async<'b>, Async<'a> * 'b>> Await two async computation in same time, if a is first finished, returns Choice1of2, otherwise returns Choice2of2.

• Async.RaceAwaitSimple(a: Async<'a>, b: Async<'a>) : Async<'a * Async<'a>> Simple version of Async.RaceAwait.

• Async.RaceAwaitSeq(a: seq<Async<'a>>) : Async<'a, seq<Async<'a>>> Await all Async<'a> in a, and return fastest result in 'a, another results in seq<Async<'a>>.

Pros and Cons

The advantages of making this adjustment to F# is having a useful function directly accessible in an idiomatic way without the need to resort to a package or using hand-written code.

The disadvantages of making this adjustment to F# is: Having more and more functions in the core library could make it harder for beginners to see the essentials.

Extra information

Estimated cost XS

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• [x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
• [x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• [x] This is not a breaking change to the F# language design
• [x] I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

[Tarmil]

I guess this can be useful. Although assuming that the returned Async represents the still-running other computation, the semantics are more fitting for Task than Async.

[vzarytovskii]

Personally, I'm not entirely sure it has to be in the standard library, as opposed to just having it in nuget package.

[Frassle]

This pretty much already exists as Choice returning things like Choice<A,B> from it is a pretty thin wrapper. Doesn't feel like something that needs to be put into core.

[Xyncgas]

Async.Choice is a thing, which ever finishes first returning first

If you are implementing this api probably return a Task to represent on-going task that can be waited for its result, instead of returning async which is more like a specification in F#, of course you can wrap the result being waited in specification that specifies you can wait on it until result is available...

Functionally speaking, you produce a bunch of Task (not .NET task, task in general), checking whether the task has finished / value / result and iterate on them again clean up the rest of the tasks

[cartermp]

Yeah, my gut feel is this belongs in an async extensions library.

[bartelink]

FWIW there are some proposals in this space that are parked as TaskEx issues in https://github.com/fsprojects/FSharp.Control.TaskSeq/issues

Anything that joins that list should generally meet the bar of being applicable across Async/Task/ValueTask

[dsyme]

Has anyone got a sample implementation based on existing Async?