Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

results were really powerful, but also really messy. I don't suggest heading in this direction. On 04/02/2019 00:39, #!/JoePea wrote: > I often find myself enjoying async functions until the time comes when I > don't want to await anything, and I want the call stack to be sync (i.e. > I d

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

well enough. >> On Sun, Feb 3, 2019 at 18:40 #!/JoePea wrote: >>> >>> I often find myself enjoying async functions until the time comes when I >>> don't want to await anything, and I want the call stack to be sync (i.e. I >>> don't want to defer if I don't hav

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

lthough it is a bit of boilerplate, it works well enough. > On Sun, Feb 3, 2019 at 18:40 #!/JoePea wrote: > >> I often find myself enjoying async functions until the time comes when I >> don't want to await anything, and I want the call stack to be sync (i.e. I &

Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

ync functions until the time comes when I > don't want to await anything, and I want the call stack to be sync (i.e. I > don't want to defer if I don't have to). > > But, async functions always return a Promise. So I find my self converting > my async functions back into normal functions so

returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

I often find myself enjoying async functions until the time comes when I don't want to await anything, and I want the call stack to be sync (i.e. I don't want to defer if I don't have to). But, async functions always return a Promise. So I find my self converting my async functions back

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

> Le 9 sept. 2018 à 23:49, Isiah Meadows a écrit : > > Does `return foo` not seemingly imply the implicit unwrapping is > occuring *inside* the function? For me, no. If I want to await the resolution of the promise `foo` before handling the `catch` or the `finally` block, I expect to add an

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

`async` function rejects. It just seems incredibly odd not to, since >> >> the usual intuition is that if an error occurs during the execution of >> >> a function, it's catchable by the parent via `try`/`catch`, even if >> >> it's a simple `return foo(.

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

rror occurs during the execution of > >> a function, it's catchable by the parent via `try`/`catch`, even if > >> it's a simple `return foo(...args)`. You see that a lot with the > >> `return await foo(...args)` step necessary within `try`/`catch` blocks > >> i

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

o(...args)`. You see that a lot with the >> `return await foo(...args)` step necessary within `try`/`catch` blocks >> in async functions, but that's literally the only time that idiom is >> necessary - it's otherwise generally equivalent to `return >> foo(...args)` mod timi

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

parent via `try`/`catch`, even if > it's a simple `return foo(...args)`. You see that a lot with the > `return await foo(...args)` step necessary within `try`/`catch` blocks > in async functions, but that's literally the only time that idiom is > necessary - it's otherwise generally

Trigger `catch`/`finally` with rejected `return` promise in `async` functions

by the parent via `try`/`catch`, even if it's a simple `return foo(...args)`. You see that a lot with the `return await foo(...args)` step necessary within `try`/`catch` blocks in async functions, but that's literally the only time that idiom is necessary - it's otherwise generally equivalent to `return foo

Re: Async functions not friendly to promise extensions

ec. I > don't know if there's some implementational reason that wasn't done, or a > philosophical reason, or what. It would certainly be more complex to > implement and understand than what's been specified; I'm not surprised > simplicity won out. > > Re: > >> var k = (async functio

Re: Async functions not friendly to promise extensions

ack there.) In that situation, in our alternate universe where async functions did what medikoo wants, the function would return a promise created by `NewPromiseCapability(%Promise%)`, since the function had to generate its own promise due to awaiting a synchronous function. E.g., the first promise it e

Re: Async functions not friendly to promise extensions

ion () { return whateverPromise; }); }; It'll be great if k resolves with promise that shares the constructor with promise returned by randomPromiseSubtypeTimeout(1000).then(...). That's my point -- View this message in context: http://mozilla.6506.n7.nabble.com/Async-functions-not-frien

Re: Async functions not friendly to promise extensions

nctions, which must be available in async functions (e.g. for fetch). You can wrap your async function call in a custom promise (which would have your desired result), changing promise instance class hierarchies on-the-fly would make promises much less deterministic than what they are now, and would​ introduc

Re: Async functions not friendly to promise extensions

> You seem to misunderstand what async functions do to be async, Your function has the same product as the following: > new Promise((acc, rej) => acc(extendedPromise)) Yes, I totally understand that, and it's clear to me that it's that way. In my post I question that design, as it se

Re: Async functions not friendly to promise extensions

resend/fwd of accidental personal reply Hello Medikoo, You seem to misunderstand what async functions do to be async. Your function has the same product as the following: new Promise((acc, rej) => acc(extendedPromise)) A promise that resolves to a extendedPromise instance. By no means

Async functions not friendly to promise extensions

with promise extensions. What was the reasoning behind such design?If not thenables in general, the promise extensions I believe should be passed through (or copied via its constructor.resolve). -- View this message in context: http://mozilla.6506.n7.nabble.com/Async-functions-not-friendly

Re: Promises, async functions, and requestAnimationFrame, together.

Ah, I think the reason that this animation loop using promises works is because promise handlers resolve in the next microtask after the current macrotask. I believe that the animation frame fires in what is essentially a macrotask, then immediately after this macrotask the resolution of the

Re: Re: await setTimeout in async functions

putation later in the event > loop, racing with another operation for a timeout, … > > > > I tend to see `setTimeout` as an old function, not meant to work well with > recent ES features (Promises and async functions), having disadvantages > (for example, error handling), and AF

Re: Re: await setTimeout in async functions

ent loop, racing with another operation for a timeout, … I tend to see `setTimeout` as an old function, not meant to work well with recent ES features (Promises and async functions), having disadvantages (for example, error handling), and AFAIK not standard. On the other hand, it’s easy to wr

Re: await setTimeout in async functions

> it was obvious from the example that it's important that `computeResult` isn't called until after the delay I was just underlying possible side effects. TBH, I don't even know why forcing a delay to an async function would be needed but yeah, definitively on the same page. I am also a bit

Re: await setTimeout in async functions

On Tue, Feb 28, 2017 at 8:14 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > In the first example, I haven't written this by accident: > > > also granting you args are those passed at the invocation time and no > possible mutation capable of affecting `computeResult` could happen

Re: await setTimeout in async functions

In the first example, I haven't written this by accident: > also granting you args are those passed at the invocation time and no possible mutation capable of affecting `computeResult` could happen later on? which is why I've shown both examples, the before `setTimeout(resolve, 1000,

Re: await setTimeout in async functions

On Tue, Feb 28, 2017 at 7:47 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > > Why not using fill setTimeout API, also granting you args are those passed > at the invocation time and no possible mutation capable of affecting > `computeResult` could happen later on? > > > ```js > >

Re: await setTimeout in async functions

risking incompatibilities > (I've seen that point reported in a recent email). > > Cancellation would probably be a sensible point, but it may also be left > to a more global solution about cancelling `async` functions. > > > > I’ve found some old discussions about a Promise-retu

Re: Scheduling of async functions

You can already mitigate it with `await undefined` or similar. On Wed, Nov 30, 2016, 12:16 Jeremy Martin <jmar...@gmail.com> wrote: > When mixing callback logic with async functions, it's up to the programmer > to choose the callback semantics that they want. > > Forcing exec

Re: Scheduling of async functions

When mixing callback logic with async functions, it's up to the programmer to choose the callback semantics that they want. Forcing execution of the async function into a future task prohibits logic that requires immediate invocation of a callback, whereas the existing semantics allow for both

Scheduling of async functions

sync function. This would not allow async functions to invoke callbacks for DOM events at all, without wrapping them in a normal function. Using an async function as an event handler directly wouldn't be a good practice anyways, because if the async function throws an exception it would lead to an unhand

Re: Re: Proposal: use "One More Point" to handle async functions

On Tue, Sep 27, 2016 at 10:23 AM, Li Xiaolong <898310...@outlook.com> wrote: > 3: the async function calls identically with sync functions, makes it hard > to check out if the function is async without jumping to the definition. > But OMP can easily be recognized. > Usually, async calls will be

Re: Proposal: use "One More Point" to handle async functions

> On Sep 27, 2016, at 6:24 PM, Li Xiaolong <898310...@outlook.com> wrote: > > > That’s not necessarily true — `await` in modules may be very different from > > this. > > I don’t know what await in modules look like. It’s still being discussed. I think there are some strong arguments for

答复: Proposal: use "One More Point" to handle async functions

> That’s not necessarily true — `await` in modules may be very different from > this. I don’t know what await in modules look like. > You might be confused about something — if an awaited Promise is rejected, > the async function can be resumed from a catch block to handle the rejection.

Re: Proposal: use "One More Point" to handle async functions

> On Sep 27, 2016, at 5:23 PM, Li Xiaolong <898310...@outlook.com> wrote: > > Sorry I’m not familiar with es7. But I still thing my OMP is better than > async/await. > 1: the await keyword can only be used in an async function, so each time you > want to await you have to add async before

Re: Re: Proposal: use "One More Point" to handle async functions

Sorry I'm not familiar with es7. But I still thing my OMP is better than async/await. 1: the await keyword can only be used in an async function, so each time you want to await you have to add async before outer function. 2: async/await still use promise to handle async, which is not as clear as

Re: Proposal: use "One More Point" to handle async functions

What you call "one more point" already exists as the `await` keyword and is much more powerful than a limited `.return` operator: Please make sure to be familiar with the topic before making further proposals. - Bergi

Proposal: use "One More Point" to handle async functions

ck style async calls that are at the end of a function, since there is no more code after the async function is called. However, as far as I can see, about half or more async functions are at the end of a function. So, the OMP is significant. ___ es-discuss mai

Re: Promises, async functions, and requestAnimationFrame, together.

) { > > this._rAF = null > > this._animationLoopStarted = false > > } > > > > this._inFrame = false > > } > > } > > ``` > > > > And the timeline results are surprising! As

Re: Promises, async functions, and requestAnimationFrame

Note that there is no guarantee that the `then` handlers (after the await) will fire in the same loop since they defer execution on their own and might defer it further. In practice I assume they'll probe to see if they need to actually schedule asynchronously or the constructed promise is

Re: Promises, async functions, and requestAnimationFrame, together.

Started = false > } > > this._inFrame = false > } > } > ``` > > And the timeline results are surprising! As you can see in the > following screenshot, all of the logic happens within the frame > (though you can see there's extra ov

Re: Promises, async functions, and requestAnimationFrame, together.

lowing screenshot, all of the logic happens within the frame (though you can see there's extra overhead from what I assume are the extra function calls due to the fact that I'm using Facebook Regenerator for the async functions): https://cloud.githubusercontent.com/assets/297678/14764237/8eb71ce2-0965-11e

Re: Promises, async functions, and requestAnimationFrame, together.

On 4/23/16 4:09 AM, Salvador de la Puente González wrote: AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. What's not obvious to me is whether it will execute it before the actual paint for the frame (i.e. before or

Re: Promises, async functions, and requestAnimationFrame, together.

AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. On Sat, Apr 23, 2016 at 1:38 AM, /#!/JoePea wrote: > Is it possible? > > I thought maybe something like this: > > ```js > function animationFrame() { >

Promises, async functions, and requestAnimationFrame, together.

Is it possible? I thought maybe something like this: ```js function animationFrame() { let resolve = null const promise = new Promise(r => resolve = r) window.requestAnimationFrame(resolve) return promise } async function game() { // the game loop while (true) {

Async functions?

In the most recent meeting notes, “async functions” were mentioned [1] (keyword: `function!`). Is there a proposal somewhere? Is it the following one? http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md

Re: Async functions?

http://wiki.ecmascript.org/doku.php?id=strawman:async_functions cheers, MarkM On Nov 28, 2013 12:34 AM, Axel Rauschmayer a...@rauschma.de wrote: In the most recent meeting notes, “async functions” were mentioned [1] (keyword: `function!`). Is there a proposal somewhere? Is it the following

Re: Async functions?

notes, “async functions” were mentioned [1] (keyword: `function!`). Is there a proposal somewhere? Is it the following one? http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#410-generator-arrow