Enable async/await to work on functions that don't just return promises.

Codefined codefined at debenclipper.com
Sun Feb 26 16:30:11 UTC 2017

Thank-you guys for the excellent problems with the previous idea, to attempt to fix as many of them as I can, here is an alteration to the proposal:

You have two types of functions, asynchronous and synchronous functions.  To distinguish between them, an asynchronous function has the keyword of `async` prepended before it.  Also, unlike the `return` statement in a synchronous function, the asynchronous code has `async return`.  Examples:
function someSync() { return "Sync"; } async function someAsync() { setTimeout(() => { async return "Async"; }, 1000); }
The synchronous code is called as one would expect, however the asynchronous code can be called in two ways:
function calleeOne() { let x = await someAsync(); } function calleeTwo() { let x = someAsync(); }
You'll notice the main difference between this latest iteration and the first proposal is that you do not need to put `async` around your callee function.  In the first case, the code waits until `x` has a value, here the value will be "Async" after one second.  In the second case, the code continues on instantly, with `x` being an automatically wrapped promise.  This has many advantages, including the most obvious example given by Florian:
// Assumes a function `someAsync()` which is an asychronous function. function c() { return d() } function d() { return await someAsync() }
You'll notice we've simply made `someAsync()` as a function, synchronous.  No code changes are needed above the `c()` function, unlike in the previous proposal iteration.

I'll be interested to see what you guys consider the advantages/disadvantages of this method, which I hope to be "the middle between two ends" on whether to go fully into promises or fully into co-routines.  Neither of which are in my opinion the optimal stance.
On 26/02/2017 14:31:30, Florian Bösch <pyalot at gmail.com> wrote:
await/async are de-facto co-routines. await/async will infect all code by necessity of software engineering. At which point they're actual co-routines, implemented badly, without a proper API.

On Sun, Feb 26, 2017 at 3:26 PM, Jerald Cohen <cohenjerald7 at gmail.com [mailto:cohenjerald7 at gmail.com]> wrote:


You sure you're not just adding more complexities to a language with features that were _meant_ to remove such complexity?

Codefined's solution to me seems to be the one with the least amount of added techniques in order to learn.  Although I understand how co-rountines are awesome, they can quickly get very confusing when you switch contexts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170226/7c40b618/attachment-0001.html>

More information about the es-discuss mailing list