And here's an example of the transform in action (borrowed from here):

async function chainAnimationsAsync(elem, animations) {
  var ret = null;
  try {
    for (var anim in animations) {
      ret = await anim(elem);
    }
  } catch(e) { /* ignore and keep going */ }
  return ret;
}

becomes

function chainAnimationsAsync(elem, animations) {
  var ret, anim;

  return wrapGenerator.async(function chainAnimationsAsync$($ctx0) {
    while (1) switch ($ctx0.prev = $ctx0.next) {
    case 0:
      ret = null;
      $ctx0.prev = 1;
      $ctx0.t0 = $ctx0.keys(animations);
    case 3:
      if (($ctx0.t1 = $ctx0.t0()).done) {
        $ctx0.next = 10;
        break;
      }

      anim = $ctx0.t1.value;
      $ctx0.next = 7;
      return anim(elem);
    case 7:
      ret = $ctx0.sent;
      $ctx0.next = 3;
      break;
    case 10:
      $ctx0.next = 14;
      break;
    case 12:
      $ctx0.prev = 12;
      $ctx0.t2 = $ctx0.catch(1);
    case 14:
      return $ctx0.abrupt("return", ret);
    case 15:
    case "end":
      return $ctx0.stop();
    }
  }, this, [[1, 12]]);
}

Regenerator doesn't support arrow generator functions yet, because there's no agreed-upon syntax for them, but I definitely intend to add support for async arrow functions.

nice! I thought it's going to take a lot more code to implement.
Excited about this! 👍

Very nice

This looks so awesome.

This is awesome.

I tried a more complex example, and ran into a problem with the handling of this:

var headers;
async function foo() {
}

This compiles to the following:

var headers;
(function foo() {
  return wrapGenerator.async(function foo$($ctx0) {
    while (1) switch ($ctx0.prev = $ctx0.next) {
    case 0:
    case "end":
      return $ctx0.stop();
    }
  }, this);
})

Note the extra parentheses added around the function declaration, turning it into a function expression and not binding a global variable to the name foo.

This only happens when a statement like var headers appears before the function declaration.

I expect this is an issue in the esprima additions for await. I tried a similar example with generator functions and do not see this issue.

A larger sample working with this is here: https://github.com/lukehoban/ecmascript-asyncawait/blob/regenerator/server.asyncawait.js as part of a branch of the async/await proposal to try to switch to using this regenerator branch for the sample instead of sweet.js macros.

Yep, I can confirm that this is related to my Esprima changes, and Recast is just trying to respect the wrong FunctionExpression type by adding the parentheses.

Will investigate.

@lukehoban Fixed this bug by adding benjamn/esprima@b714306 to my https://github.com/ariya/esprima/pull/234 pull request. In short, I was misusing peekLineTerminator() in matchAsync.

I also switched getCollaboratorImages back to a function declaration in your server.asyncawait.js file, and the transformation did not add parentheses to it.

@lukehoban where did TC39 come down on await*? The notes seem to indicate they don't want it if there's no analogy to yield*, which is fine with me.

Hey everybody, great work @benjamn . I see no movement since April, how's the progress on this?
This is such a nice feature to have!

Nice!

👍