[crenshaw]

What the C# designers don't seem to have noticed is that async/await is very closely related to LINQ and could have been built as a new syntax on top of LINQ.

Considering the C# designers include Erik Meijer and work closely with Don Syme, I find it hard to believe that they didn't notice this. But you're right, it's not as powerful or general as what is in F# (which I really need to learn better, as every time I look at it, I want to code in it).

I suspect the C# designers looked at what one of the biggest problems they have is, and it is asynchronous computation (especially w/ respect to the UI thread) and said that F# async workflows solve this problem. But too generally. What do I mean by that. With the current C# solution the syntatic changes are minimal to a completely sequential program. It's not as general, but easier to write and understand.

I wouldn't be surprised if C# added async workflows full on in a future version, when they'll point to async/await and say "you've been doing it for years -- it's not hard at all!"

[jules]

The full power of F# async workflows can be had with the same syntax async/await has now. Basically async workflows could have been a more convenient syntax for let! in F# async workflows, in the sense that you can directly apply await inside an expression instead of having to insert a let statement:

    ... Foo(await m) ...

Instead of, in F#:

    let! x = m
    ... foo x ...

It is certainly possible that the C# designers did recognize the possibility to make await work for any monad, but decided against it because it could possibly result in confusing code or worse performance.

If that's the case then it would be great to hear the reason from one of you who are on the C# design team and reading news.yc :)

[crenshaw]

If that's the case then it would be great to hear the reason from one of you who are on the C# design team and reading news.yc :)

I'd second that. Maybe someone @MS could send this to the Async team?