Is it possible to short-circuit a running async function like one can do with a generator by calling its return method?

A use case would be to have a finally block invoked in order to clean up resources, etc.

This avoids using the generator machinery in favor of simply suspending and resuming execution contexts as appropriate. Fixes #49.

Now most of the ceremony comes from PromiseCapability stuff. We could simplify it a bit if we did something like NewBuiltInPromise(), then use PromiseResolve and PromiseReject on it (which can never throw), instead of messing around with promise capabilities (which in theory can throw, although for %Promise% they cannot). PerformPromiseThen is also a bit awkward when you want to ignore the return value. But, not a big deal IMO.

Maybe this is part of the spec, but I was not able to find it in the text.

Will it be possible to check if a function is an async function? This would be beneficial developing libraries around async functions. Just to make my point clear with pseudo code:

async myFunc() {

}

myFync.isAsync // true

In the proposal, it looks like "await" is to be used inside async functions.

Can "await" be used in top-level code?

The reason is, when teaching students, it makes a lot of sense to start with top-level code that does not contain function definitions, and it also makes sense to "await input", such as in this example using Iced CoffeeScript's "await". What would this example look like in this proposal?

http://pencilcode.net/edit/guessmynumber

Let's say I have an async function:

async function foo() {
    try {
        var db = await getDatabase();
        await new Promise(() => {}); // db.doSomethingThatForgetsToResolve()
    } finally {
        if(db) db.close();
    }
}

And I call it:

var g = f();

• Does the finally block ever run?
• Can garbage collection ever happen?

I was playing around with the current experimental implementation of async/await in Babel and thought it might be cool to be able to await on arguments. The most basic example:

async function double(await num) {
  return num * 2;
}

This is the same as the following ES6:

function double(num) {
  return num.then(x => x * 2);
}

Or the following ES5:

function double(num) {
  return num.then(function (x) {
    return x * 2;
  });
}

As another example, consider awaiting on multiple arguments:

async function multiply(await first, await second) {
  return first * second;
}

~~As far as I'm aware, this is the best analog in the current proposal:~~

Better analog (as pointed out in the comments):

async function multiply(first, second) {
  [first, second] = [await first, await second];
  return first * second;
}

And as far as I'm aware, this is the best analog in ES6:

function multiply(first, second) {
  return Promise.all([first, second]).then(([a, b]) => a * b);
}

Extending this even further, we can use the new ES6 arguments functionality with await:

async function multiply(await {num: first}, await {num: second}) {
  return first * second;
}

Which is the same as:

function multiply(first, second) {
  return Promise.all([first, second]).then(([{num: first}, {num: second}]) => first * second);
}

Additional example for awaiting on a property of an argument:

async function double({await num}) {
  return num * 2;
}

Which is the same as:

function double(obj) {
  return obj.then(({num}) => num * 2);
}

I'm having spotty debugging experiences when I try to debug code with async/await using transform-async-to-generator babel plugin.

@amcdnl had the same problems and opened an issue at https://github.com/mozilla/source-map/issues/221 which describes the issue in more detail and has some interesting discussion about debugging async/await.

Is the debugging experience part of this proposal? Was this thought about before (e.g. in respect to how other languages having async/await syntax handle debugging)?

Promises can be "handled" after they are rejected. That is, one can call a promise's reject callback before providing a catch handler. This behavior is a little bothersome to me because one can write...

var promise = new Promise(function(resolve) {
    kjjdjf(); // this function does not exist
});

... and in this case, the Promise is rejected silently. If one forgets to add a catch handler, code will continue to silently run without errors. This could lead to lingering and hard-to-find bugs.

In the case of Node.js, there is talk of handling these unhandled Promise rejections and reporting the problems. This brings me to ES7 async/await. Consider this example:

async function getReadyForBed() {
  let teethPromise = brushTeeth();
  let tempPromise = getRoomTemperature();

  // Change clothes based on room temperature
  let temp = await tempPromise;
  // Assume `changeClothes` also returns a Promise
  if(temp > 20) {
    await changeClothes("warm");
  } else {
    await changeClothes("cold");
  }

  await teethPromise;
}

In the example above, suppose teethPromise was rejected (Error: out of toothpaste!) before getRoomTemperature was fulfilled. In this case, there would be an unhandled Promise rejection until await teethPromise.

My point is this... if we consider unhandled Promise rejections to be a problem, Promises that are later handled by an await might get inadvertently reported as bugs. Then again, if we consider unhandled Promise rejections to not be problematic, legitimate bugs might not get reported.

Thoughts on this?

This is related to the discussion found in the Node.js project here: https://github.com/nodejs/node/issues/830

It would be a good thing if async functions would return the same type of promise that was awaited on in their function bodies. This would align with how typescript is implementing it (according to this issue). The async/await keywords could then be used together with various promise implementations without loosing the bells and whistles that comes with various Promise libraries such as bluebird, Q, WinJS and Dexie.

External Promise implementations can have features that would be lost if converting them to the 'standard' Promise as suggested in the readme of this repository.

Therefore, I would propose a more adaptive implemetation of spawn() that can accept and forward any A+ compatible Promise that was awaited for:

function spawn(genF, self) {
    var gen = genF.call(self);
    function step(nextF,initial) {
        var next = nextF();
        if (next.done) {
            // finished with success, resolve the promise
            return initial ?

                // Nothing was awaited. Direct return value must be converted
                // to promise:
                Promise.resolve(next.value) :

                // Return the value as is and let the promise
                // implementation take care of the A+ compatible promise chain
                next.value;
        }
        // not finished, chain off the yielded promise and `step` again
        if (!next.value || typeof next.value.then !== 'function')
            return step(function(){
                // Don't accept awaiting a non-promise such as "await 3;".
                // By not accepting that, we could detect bugs better.
                return gen.throw(new TypeError("Only acceptable to await a Thenable"));
            }, initial);
        return next.value.then(function (v) {
            return step(function () { return gen.next(v); });
        }, function (e) {
            return step(function () { return gen.throw(e); });
        });
    }

    try {
        return step(function() { return gen.next(undefined); }, true);
    } catch (e) {
        // Failure before code has yielded any Promise.
        return Promise.reject(e);
    }
}

Specifically, for my library, Dexie.js, there is a feature that enables 'Promise-Specific Data' which is analogue to 'thread static data' for promises. The entire Dexie API depends on that feature because it enables things like reentrant mutexes, implicit transaction scope, sub transaction awareness and some more API sugar. I believe that bluebird, Q, WinJS and others also would benefit from having this openess in how async/await behave.

By not binding the async keyword to a specific implementation of Promise, we would allow new Promise implementations with features that we cannot think of today and still use them with async/await.

Assuming getJSON returns a promise for some JSON, does this work:

async function renderChapters(urls) {
  urls.map(getJSON).forEach(j => addToPage((await j).html));
}

Does the await within the arrow function halt the execution of both the forEach and renderChapters, or does it error because the arrow function is not an async function?

If not, should we have a way to await to the parent async function?

It might be nice to allow new on an async function and have it do something useful...

async function Person() {
  this.name = await getName();
}

// seems weird-ish.
var p = new Person();
p.then(person => console.log(person.name));


// but seems better in another async function
async function CreatePerson() {
  var person = await new Person();
  // ...
  return person;
}

// also allowing new argues for an additional async form:
class Foo {
    async constructor() { ... }
}

The behavior of generators is to allow new (IOW, all other function forms can be newed) which argues for allowing it. However, generators don't allow this in their body. This would be a needless restriction for async functions so I'm not sure it applies.

If anyone is aware of code today where new is expected to return a promise for an instance it would be a strong argument in favor of allowing new.

I think the only viable alternative is to make newing an async function an error.