> You're both complaining about extra keywords while trying to make the case of adding yet another one
I did no such thing. async is already a keyword in F#, I'm just saying they should drop the brackets and remove the required return statement.
> In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case
It would make the language easier to read, for one, and would reduce the amount of specialized syntax needed for specific features. It would preserve the original ML-style syntax for an extremely common operation and not force users into wrapping anything upstream of an async call in a computation block, which is the ugliest syntax feature of F#
> Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after
I understand that, and my argument is they failed to do so. The syntax looks bad. They could keep it for all I care, but they should add even more sugar on top to make it not look so bad.
'async' is not a keyword in F#, it's a builder instance no different to the ones that you can create. It's just built in to the standard library.
The return statement is only required if you want to return something form the computation expression. In your example you use async { let! x = f(); return x}, which can be reduced to async { return! f()}, which can be reduced to f().
The rest is your opinion that I don't agree with.
The distinction in this case is utterly meaningless. This is about the ergonomics of the language. Which are lacking the minute to break out of pure functional land
Read this first: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
There are multiple alternate asynchronous computation expression implementations which give different ergonomics and behavior (like https://github.com/TheAngryByrd/IcedTasks). There's an entire CE extension to specifically enable this kind of convenience and flexibility too: https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...
None of this is possible in C#, at least without jumping through many hoops and ending up with extra boilerplate (and this is okay, C# has enough of its own complexity). As cjbgkagh noted, providing this type of control is the whole point and what makes F# so powerful.