Add `syncTask` builder (similar to `backgroundTask`)

[Lanayx]

I propose we add syncTask builder (similar to backgroundTask), which will greatly lower F# entry barrier. Today most of the .NET API's become asynchronous and most of 10-liner "Hello world" apps require unnecessary cognitive load of adding .GetAwaiter().GetResult() or Async.runSynchronously, for example

(task {
    let tempFilePath = Path.GetTempFileName();
    do! File.WriteAllTextAsync(tempFilePath, "Hello, World!")
    let! readContent = File.ReadAllTextAsync(tempFilePath)
    printfn $"File content: %s{readContent}"
}).GetAwaiter().GetResult()

New builder will allow to simplify that

syncTask {
    let tempFilePath = Path.GetTempFileName();
    do! File.WriteAllTextAsync(tempFilePath, "Hello, World!")
    let! readContent = File.ReadAllTextAsync(tempFilePath)
    printfn $"File content: %s{readContent}"
}

This problem doesn't exist in C# due to ability to write await in the top level file.

The existing way of approaching this problem in F# are:

1. Using shorthand lambdas

task {
    let tempFilePath = Path.GetTempFileName();
    do! File.WriteAllTextAsync(tempFilePath, "Hello, World!")
    let! readContent = File.ReadAllTextAsync(tempFilePath)
    printfn $"File content: %s{readContent}"
}
|> _.GetAwaiter().GetResult()

2. Using custom operators

let inline (~+) (t: Task<'a>) : 'a = t.GetAwaiter().GetResult()

+task {
    let tempFilePath = Path.GetTempFileName();
    do! File.WriteAllTextAsync(tempFilePath, "Hello, World!")
    let! readContent = File.ReadAllTextAsync(tempFilePath)
    printfn $"File content: %s{readContent}"
}

3. Writing custom builders

type SyncTaskBuilder() =
    member inline _.Bind(t: ValueTask<_>, cont) =
        task.Bind(t, cont)
    member inline _.Bind(t: Task<_>, cont) =
        task.Bind(t, cont)
    member inline _.Zero() =
        task.Zero()
    member inline _.Delay(f) =
        task.Delay(f)
    member inline _.Combine(t1, t2) =
        task.Combine(t1, t2)
    member inline _.While(cond, t) =
        task.While(cond, t)
    member inline _.Return(x)  =
        task.Return(x)
    member inline _.ReturnFrom(t) =
        task.ReturnFrom(t)
    member inline _.Run(f) =
        task.Run(f).GetAwaiter().GetResult()

let syncTask = SyncTaskBuilder()

Pros and Cons

The advantages of making this adjustment to F# are easier reading and writing code for newcomers, but also for F# demos with single-line files

The disadvantage of making this adjustment to F# is making easier to write blocking asynchronous code.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S

Related suggestions:
#1022
#1042
#581

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• 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
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to the F# language design
• 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 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[ForNeVeR]

I often dream of something like

task {
    let tempFilePath = Path.GetTempFileName();
    do! File.WriteAllTextAsync(tempFilePath, "Hello, World!")
    let! readContent = File.ReadAllTextAsync(tempFilePath)
    printfn $"File content: %s{readContent}"
} |> Task.RunSynchronously

(as a full analog of Async.RunSynchronously)

Writing all the braces and .GetAwaiter().GetResult() in the user code, indeed, feels clunky.

[jwosty]

@ForNeVeR Agreed, I'd much prefer that approach; it feels more aligned with the spirit of composability

[Lanayx]

I often dream of something like

task {
let tempFilePath = Path.GetTempFileName();
do! File.WriteAllTextAsync(tempFilePath, "Hello, World!")
let! readContent = File.ReadAllTextAsync(tempFilePath)
printfn $"File content: %s{readContent}"
} |> Task.RunSynchronously

(as a full analog of Async.RunSynchronously)

Writing all the braces and .GetAwaiter().GetResult() in the user code, indeed, feels clunky.

I'd still prefer new builder over such function because:

1. Run part is misleading, since task is already running
2. It is still extra code compared to C#
3. Builder will reduce the harm scope, function is easy to use and it will "feel" correct (although in many cases it won't be)

[WizMe-M]

In my opinion both approaches (syncTask and Task.RunSynchronously) fit in their own use-cases:

• syncTask - execute multiple tasks in CE;
• Task.RunSynchronously - wait single task on top-level.

syncTask is shorter and more concise.

Task.RunSynchronously is more verbose, can be used in function composition, pipelines and can have parameters such as whether execute .ConfigureAwait(false).

I'd prefer to have both of them

[kerams]

The solution to this "problem" are Task<int> entry points. Enshrining syncTask in FSharp.Core will make it seem like we're promoting the blocking wait anti-pattern for general use. I think this will do more harm to newcomers in the long run as they might make a habit out of using this construct and then wonder about the deadlocks it causes.

[Lanayx]

The solution to this "problem" are Task entry points.

My main focus is not on files with entry points, but on the short single-file console apps without explicit entry points, where blocking wait is not an anti-pattern, but a necessity. I don't believe that explicit synchronous builder can make more harm than explicit Async.runSynchronously available today for async. Some top-level task support like in C# might work, but for me it feels less F#-native than explicit builder, because F# comes with multiple async implementations.