[Strilanc]

Async/await makes a lot of asynchronous code easier to write, which is great, but it amplifies some of the mistakes people were already making. The two examples in the post are:

- Developers won't anticipate that accessing a task's Result property can introduce a deadlock.

- Developers won't anticipate race conditions due to a concurrent SynchronizationContext.

The problem from the first example actually does happen quite often. There are plenty of stackoverflow questions and blog posts about it. IMO there should be compiler warnings whenever you use Task.Result or Task.Wait. Actually I would prefer compile errors instead of just warnings, and for the implementations of Result and Wait to just be `throw new WHAT_IS_WRONG_WITH_YOU_DO_NOT_BLOCK_ON_TASKS_AAARGH_EXCEPTION()`, but that might be a bit harsh.

The problem from the second example is not really an issue with await/async as opposed to a deeper language issue. Any concurrency mechanism in C# will be vulnerable to the fact that you can define and access shared mutable variables (including the solution proposed in the post).

[final]

Yield, foreach, LINQ all have many similar problems, compared to a for loop, but nonetheless greatly increase productivity. Given a little time, the devs will learn to use async properly.

[Strilanc]

I agree (and am the person you replied to).