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

Actually, this proposal would be a revolution and I can think of too many edge cases to make it viable. Consider: async function foo() { async function bar() { [1,2,3].forEach(async function() { async return 3; }); } return (await bar()) + 39; } What

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

On Mon, Feb 27, 2017 at 12:41 AM, Isiah Meadows wrote: > May I add one more thing: the main topic this was about is adapting > non-standard async APIs (like Node's error-first callback idiom) to the land > of promises. Async functions and iterators are incredibly useful

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

I had a similar thought a while ago for adapting non-promise functions, by way of `async.resolve()` and `async.reject()`: ```javascript async function asyncFunction() { someAsync('data', (err, data) => { if (err) async.reject(err); async.resolve(data); }) } ``` This

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

May I add one more thing: the main topic this was about is adapting non-standard async APIs (like Node's error-first callback idiom) to the land of promises. Async functions and iterators are incredibly useful when you're dealing with just promises, especially consuming them, but this is about

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

Codefined, just out of curiousity, do you have anything to do with this proposal that got announced today ? Or is it just a coincidence? :) ​ On Sun, Feb 26, 2017 at 3:07 PM Dean Tribble wrote: > Should `callee()` be asynchronous

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

> > Should `callee()` be asynchronous here? To my mind, no, it shouldn't. > Every single line here is synchronous, so the function itself should surely > be synchronous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async

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

A very interesting read indeed Alexander!  Gave me a new example to give when people ask what the worst code I'd ever seen was: Promise DoSomething(Promise cmd) { return cmd.WhenResolved( s => { if (s == "...") { return DoSomethingElse(...).WhenResolved( v => { return ...; }, e => { Log(e);

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

Required reading for anyone who wants to be so... opinionated ;) http://joeduffyblog.com/2015/11/19/asynchronous-everything/ On Sun, 26 Feb 2017 at 16:35, Florian Bösch wrote: > On Sun, Feb 26, 2017 at 5:30 PM, Codefined > wrote: > > I'll be

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

You seem to be feel incredibly jaded about nearly everything posted here.   Perhaps if you suggested your own proposal that showed the clear advantages of co-routines as you see it, then you might solve some of the issues instead of just whining about it. I assume that every single Javascript

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

On Sun, Feb 26, 2017 at 5:30 PM, Codefined wrote: > 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.

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

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

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

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 wrote: > Florian, > > You sure

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

Florian, 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,

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

On Sun, Feb 26, 2017 at 2:51 PM, Codefined wrote: > What I feel we need is some way of making an asynchronous function > "appear" to be synchronous. > That's what co-routines are. Best practices for co-routines is usually to have some sort of API to spawn them (like

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

Ah, that would indeed make sense.  What I feel we need is some way of making an asynchronous function "appear" to be synchronous.  Actually that's sort of what I expected async/await to do, but that only seems to affect where it's called, as opposed to the function

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

On Sun, Feb 26, 2017 at 2:17 PM, Codefined wrote: > Because `d()` is no longer an asynchronous function, you can call it like > normal, surely? > Only async functions can await. Only await pauses execution to wait on async.

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

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

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

On Sun, Feb 26, 2017 at 2:08 PM, Jerald Cohen wrote: > (although, at the moment, I fail to see why one can't just use a normal > "return"). > You're probably unaware of this, but there is a fixation in this community, and many adjacent ones, that if you sprinkle syntax

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

To illustrate that, I went to Github , I looked for repositories that match "await" and are JS (471 repositories). The first few hits where microframeworks with minimal code or language parser, but then comes:

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

I actually really like this idea. It reminds me of the C# syntax to try to accomplish the same thing. Although under the bonnet C# uses "tasks", which appear to be their form of promises, the surface code does look very similar, take for example: public async Task MyMethodAsync(){ Task

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

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(); }

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

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 wrote: > On Sat, Feb 25, 2017 at 11:55 PM, Codefined

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

Hello Isiah, I'm not sure you understand my point on why this is important.  Although if you understand all the concepts used here it's logical, it's very intimidating to a person newer to Javascript.  This could be especially true in a framework like Node.JS, where you can run into a

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

Here's my thoughts: 1. There's minimal benefit to be gained with your example, since it can already be simulated very similarly with the current API: function asyncFunction() { return new Promise(resolve => { someAsync('data', (...args) => resolve(args)) }) } 2. This won't

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

On Sat, Feb 25, 2017 at 11:55 PM, Codefined 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