Hey Florian, Why do we even need to do that? async function someAsync() { something(() => { return "hello"; }); } let d = function() { return await someAsync(); } let c = function() { return d(); } Because `d()` is no longer an asynchronous function, you can call it like normal, surely?
On 26/02/2017 12:44:01, Florian Bösch <pya...@gmail.com> wrote: It would be nice if there even was an argument, but there isn't. There isn't because async/await naturally devolves into implicit coroutines, so any argument would be moot. To illustrate, suppose you have these 4 functions: let a = function(){ return b(); } let b = function(){ return c(); } let c = function(){ return d(); } let d = function(){ return whatever(); } Call chains like this are typical. It's the staple of software engineering (for reasons of proper separation of concerns, reuse of utility code, etc.). If you believe that there is an argument about this being exemplary, it would be impossible to have an argument with you about software engineering at all. Of course real-world examples are more complex and don't just return whatever the underlying function produced, but as a control flow example it suffices. These chains are often much deeper than 4 levels, it's not uncommon to encounter call chains 10, 15, 20 or 30 layers deep. Now let's suppose you figure that function d wants to do something asynchronous. So you go and do: let d = function(){ return xhr(); } But of course that doesn't work, because d is not async. So you go and do: let d = async function(){ return await xhr(); } Of course that doesn't work because c is not async, and so forth, so eventually your code looks like that. let a = async function(){ return await b(); } let b = async function(){ return await c(); } let c = async function(){ return await d(); } let d = async function(){ return await xhr(); } In essence, you've applied to following two regular expression: s/function/await function/g and s/.+?\(\)/await ()/ . Of course that'd be horrid to do, so in reality you'd please use a proper JS parser. How did your code look before you applied these regular expressions? Well, it looks exactly like at the start. let a = function(){ return b(); } let b = function(){ return c(); } let c = function(){ return d(); } let d = function(){ return xhr(); } But it isn't like at the start, because now it can trigger race conditions and is asynchronous. It is in fact now idempotent with true co-routines, except some unnecessary code transmoglification. This conclusively proves that await/async is an inconvenient clutch that naturally devolves into true co-routines. Now you might try to argue, that real-world code isn't just going to prefix every function call with await and every function body with async and stay that way. However, this would be in invalid argument for actual real-world code, because. People don't just constantly switch back and forth and re-engineer their code just because they want something async to happen underneath. You don't go and bicycle repair every call and function definition if you should decide to toggle synchronous or asynchronous. Therefore, since prefixing everything works no matter if it is asynchronous or synchronous, you will stay with the prefixes once you've added them. Which not only guarantees that async/await devolves into true co-routines, but it also gurantees that they proliferate everything and once they're in, they're never going out. And that's why it isn't an argument. On Sun, Feb 26, 2017 at 12:05 PM, Alexander Jones <a...@weej.com [mailto:a...@weej.com]> wrote: Florian, you shouldn't pass the argument of explicit vs implicit coroutines off as being so simple. There are many compelling arguments for both! Please Google them! On Sun, 26 Feb 2017 at 00:01, Florian Bösch <pya...@gmail.com [mailto:pya...@gmail.com]> wrote: On Sat, Feb 25, 2017 at 11:55 PM, Codefined <codefi...@debenclipper.com [mailto:codefi...@debenclipper.com]> wrote: This seems to be so very confusing for anybody new studying this language, almost everyone I talk to gets stuck up on some part of it. Promises are bad, and mixing them with async/await is worse. Should never have been added to any kind of standard. async function asyncFunction() { let [err, data] = await asyncFunction() } function asyncFunction(){ return otherAsyncFunction(); } Even simpler, you'd just need co-routines. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org [mailto:es-discuss@mozilla.org] https://mail.mozilla.org/listinfo/es-discuss [https://mail.mozilla.org/listinfo/es-discuss]
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss