It works like in every other language that supports async/await. Compiler will convert code inside async method into a state machine to prevent it from locking thread during await calls.

If you don't uses async you have to do compiler's job yourself.

But why do we need a new keyword to express this? Isn't the return type sufficient?

No, because you can write async functions without using async/await. Using callback for example:

  Future<int> foo() {
      return Future.delayed(Duration(seconds: 1)).then((x) => 1);
  }

In this case there is no compiler magic needed. If you ask why async keyword is needed if we can just infer it from await inside the method body - probably only for readability.

async is part of the method signature, the public facing part of the method. But it controls an implementation detail, namely whether the function body may use await (as you say asynchronous functions are not required to use await).

I found a link [1] that described async as a compatibility affordance in C# 5: legacy code may use await as a variable name, so async opts into the contextual await keyword. But Dart doesn't have such legacy, so the keyword doesn't seem as well motivated.

https://blogs.msdn.microsoft.com/ericlippert/2010/11/11/asyn...

> What is the difference between an async method and a method that returns a Future?

There's no difference for callers of the method, but you can only use await in methods that are async.

An async method can use await within it. A method can return a future but not be able to use the await keyword.

What is the point of this restriction? Why not just allow all Future-returning functions to use await?

Async methods also allow you to return values which will be returned as futures.

For example:

  return 4;

If the function is marked async, the return value should be Future<int>.

If you allow a non-async method use await, you get into this situation:

  Future<int> foo(){
    int result = await something ();
    // How to return "result" and still make compiler happy?
  }

Why not just some generic function T -> Future<T>?

It sounds like the async keyword allows for a particular implicit type conversion within the function body, but on return statements only. That's a pretty thin justification for a keyword.