There are several answers here, and all of them talk about what async methods do, but none of them answer the question, which is why async is needed as a keyword that goes in the function declaration.

It’s not “to direct the compiler to transform the function in a special way”; await alone could do that. Why? Because C# already has another mechanism where the presence of a special keyword in the method body causes the compiler to perform extreme (and very similar to async/await) transformations on the method body: yield.

Except that yield isn’t its own keyword in C#, and understanding why will explain async as well. Unlike in most languages that support this mechanism, in C# you can’t say yield value; You have to say yield return value; instead. Why? Because it was added in to the language after C# already existed, and it was quite reasonable to assume that someone, somewhere, might have used yield as the name of a variable. But because there was no pre-existing scenario in which <variable name> return was syntactically correct, yield return got added to the language to make it possible to introduce generators while maintaining 100% backwards compatibility with existing code.

And this is why async was added as a function modifier: to avoid breaking existing code that used await as a variable name. Since no async methods already existed, no old code is invalidated, and in new code, the compiler can use the presence of the async tag to know that await should be treated as a keyword and not an identifier.

it changes the method from a normal method to a object with callback which requires a totally different approach for code generation

and when something drastic like that happens it is customary to signify it clearly (we learned that lesson from C++)

The whole idea with keywords like “async” or “unsafe” is to remove ambiguity as to how the code they modify should be treated. In the case of the async keyword, it tells the compiler to treat the method modified as something that does not need to return immediately. This allows for the thread where this method is used to continue without having to wait on the results of that method. It’s effectively a code optimization.

OK, here is my take on it.

There is something called coroutines that has been known for decades. (“Knuth and Hopper”-class “for decades”) They are generalizations of subroutines, in such as not only do they get and release control at function start and return statement, but they also do it at specific points (suspension points). A subroutine is a coroutine with no suspension points.

They are PLAIN EASY to implement with C macros, as shown in the following paper about “protothreads”. (http://dunkels.com/adam/dunkels06protothreads.pdf) Read it. I’ll wait…

The bottom line of this is that the macros create a big switch, and a case label at each suspension point. At each suspension point, the function stores the value of the immediately following case label, so that it knows where to resume execution next time it is called. And it returns control to the caller.

This is done without modifying the apparent flow of control of the code described in the “protothread”.

Imagine now that you have a big loop calling all these “protothreads” in turn, and you get concurrently executing “protothreads” on a single thread.

This approach has two drawbacks:

1. You cannot keep state in local variables between resumptions.
2. You cannot suspend the “protothread” from an arbitrary call depth. (all suspension points must be at level 0)

There are workarounds for both:

1. All local variables must be pulled up to the context of the protothread (context which is already needed by the fact the protothread must store its next resumption point)
2. If you feel you really need to call another protothread from a protothread, “spawn” a child protothread and suspend until completion of the child.

And if you had compiler support to do the rewrite work that the macros and workaround do, well, you could just write your protothread code just as you intend and insert suspension points with a keyword.

And this is what async and await are all about: creating (stackless) coroutines.

The coroutines in C# are reified as objects of (generic or non-generic) class Task.

I find these keywords very misleading. My mental reading is:

• async as “suspensible”
• await as “suspend until completion of”
• Task as “future …”

Now. Do we really need to mark the function async? Apart from saying that it should trigger the code rewrite mechanisms to make the function a coroutine, it resolves some ambiguities. Consider this code.

public Task<object> AmIACoroutine() {
    var tcs = new TaskCompletionSource<object>();
    return tcs.Task;
}

Assuming that async is not mandatory, is this a coroutine or a normal function? Should the compiler rewrite it as a coroutine or not? Both could be possible with different eventual semantics.