Transpiling async/await to promises instead of generators for es5

[sheerun]

According to #1564 async/await support in ES5 typescript depends on generators in ES5 to be implemented. But ES5 generators implementation has been declined.

I hope it won't mean that async/await support won't be unsupported as well, because async/await depending on generators is a false assumption, as demonstrated by fast-async. Instead of compiling async/await to generators as intermediate step, you can go straight to Promises. It results in ES5 target support and better looking code.

Could you consider implementing async/await support for ES5 target without focusing so much on generators? Most of the community finds async/await support more important.

Ping @RyanCavanaugh

[aluanhaddad]

async/await is already implemented via partial generator support.

npm install typescript@next

Apparently a subset of generator semantics is all that is required such that, while downlevel emit of Generators as a language feature was declined. async/await is here. Pick a Promise polyfill and try it.

I don't know the reasons for choosing generators, although I would be very much interested in finding out why they were chosen over promises. I suspect it has to do with exceptions.

[sheerun]

Ach, yes @jonaskello mentioned it just after I posted this issue.

I'm leaving this open, though, as it straight-to-promise transcompilation could result in more readable and smaller code. I've prepared comparison of current typescript transcompilation and fast-async one in: https://gist.github.com/sheerun/68e182127f9acb894b43efed5f592d6e

Notice while preceeding "library" code is little smaller in typescript's version (though probably not in complexity, just code size), the transcompiled code is more readable and shorter:

function something() {
    return __awaiter(this, void 0, void 0, function () {
        var result;
        return __generator(this, function (_a) {
            switch (_a.label) {
                case 0: return [4 /*yield*/, fetch('http://www.google.pl')];
                case 1:
                    result = _a.sent();
                    return [2 /*return*/, 'foobar'];
            }
        });
    });
}

vs

function something() {
  return new Promise(function ($return, $error) {
    var result;
    return fetch('http://www.google.pl').then(function ($await_1) {
      result = $await_1;
      return $return('foobar');
    }.$asyncbind(this, $error), $error);
  }.$asyncbind(this));
}

[sheerun]

As for the benefit of using generators instead of promises, maybe it leads to less closures created.

[jonaskello]

I think implementing with generators is probably more straightforward as async/await is basically just synthetic sugar over generators. Both implement the same exact same idea which is co-routines. Promises/Tasks is not a related idea, it just helps with the async/await sugar. Before C# got async/await it was easily emulated using IEnumerabe/yield which is the C# equivalent of JS generator functions.

[mhegazy]

I'm leaving this open, though, as it straight-to-promise transcompilation could result in more readable and smaller code

this may be true for code with small list of await expressions. but it does not scale for the general case. once you have a loop with an await expression, you can not use promises.

But ES5 generators implementation has been declined.

Supporting generators for ES5/ES3 is tracked by #1564