> AFAIK not standard. FYI it's standard for the DOM world.
https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#timers About cancelability, if the purpose is to delay stressful operations, I would definitively like to cancel that whenever is needed ;-) A generic Promise based `delay(ms)` seems to be trivial enough I don't think specs should be bothered. I mean, this is all it takes, right? ```js const delay = ms => new Promise(r => setTimeout(r, ms)); ``` Regards On Wed, Mar 1, 2017 at 1:55 PM, Jérémy Judéaux <[email protected]> wrote: > > I don't even know why forcing a delay to an async function would be > needed > > > > In my opinion, for the same reasons calling `setTimeout` would have been > needed: batching several calls together for a request, simulating i/o > latency, delaying the rest of an expensive computation 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 AFAIK not standard. > > > > On the other hand, it’s easy to write or find a Promise-returning delay. > And there is the cancellation issue (but I have the intuition that a “delay > function” now will be compatible with any “cancellation solution” later). > > > > I believe that, at some point, the “delaying” feature should be reviewed. > Maybe not now. > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
