It just adds the necessary logic to allow releasing the current thread, and marshal the result back on that same thread [...]
This depends on the current SynchronizationContext and/or TaskScheduler (default one for GUI thread resumes on same context) and whether ConfigureAwait() was specified or not.
In other words, use async only for I/O bound operations.
It seems too restricitve. There are other scenarios where async/await might make sense. For example to make a UI responsive. Additionally, much like the IDisposable patter, async/await is a kind of "contaminating" pattern and when you start using it you often have to go all the way and make other methods async as well, avoiding the smelly async void case.
This depends on the current SynchronizationContext and/or TaskScheduler (default one for GUI thread resumes on same context) and whether
ConfigureAwait()was specified or not.It seems too restricitve. There are other scenarios where async/await might make sense. For example to make a UI responsive. Additionally, much like the IDisposable patter, async/await is a kind of "contaminating" pattern and when you start using it you often have to go all the way and make other methods
asyncas well, avoiding the smellyasync voidcase.