A setTimeout that returns a promise that resolves after specified time.

[jisaacks]

I really love Promise.resolve("some value"), however if you want to delay this resolving you have to do something much uglier like

new Promise(resolve => setTimeout(() => resolve("some value"), 1000));

Would love a way to create a promise that waits and resolves. I made a proposal for Promise.after to ES and was informed it is a better fit to recommend here.

It seems a global function might make more sense in this context. Maybe something like resolveIn(1000) that would return a promise that resolves in 1000 milliseconds. This could even be implemented like so:

function resolveIn(milliseconds) {
    return new Promise(resolve => setTimeout(() => resolve(milliseconds), milliseconds));
}

And could be used like:

resolveIn(1000).then(/* do something */);

And could be used to resolve a specified value after a delay like so:

resolveIn(1000).then(() => "some value").then(/* do something with "some value" */);

[domenic]

I am in support of this idea (with a better name, but we can bikeshed that later). I would like to hear if any implementers would implement this assuming I specced it.

[AlicanC]

How about cancelation? clearResolveIn(promise)? Cancelable promises?

[domenic]

I think we would have to wait for cancelable promises (in whatever form they show up in). That might be enough to sink this feature until that work is done, but I personally don't think it's necessary---adding it right now, and making it cancelable later, would be OK in my book.

[AlicanC]

Are we absolutely sure that making this cancelable later won't be a breaking change or introduce nasty duplication like cancelableResolveIn() or CancelablePromise.after()?

Without cancelation, this proposal is just a shortcut to a one-liner which we can (and do) live without. Achieving clearTimeout functionality with promises is a lot harder and it would be better if this proposal could solve that issue.

[jisaacks]

Are we absolutely sure that making this cancelable later won't be a breaking change or introduce nasty duplication like cancelableResolveIn() or CancelablePromise.after()?

If promises become cancelable in the future, this would automatically become cancelable too.

it would be better if this proposal could solve that issue.

These are 2 separate issues.

[domenic]

Are we absolutely sure that making this cancelable later won't be a breaking change

Yes, sort of. From one perspective, it could be a breaking change, since code that previously assumed a promise would never be canceled would suddenly start to have to deal with that. This is a general problem with cancelable promises across the platform and is part of the reason why I am scared to start working on them because it will start causing lots of debates. (Which I really do not want to reiterate in this thread; so let's try to drop this line of discussion.)

or introduce nasty duplication like cancelableResolveIn() or CancelablePromise.after()?

We can guarantee this will not happen, yes.

Without cancelation, this proposal is just a shortcut to a one-liner which we can (and do) live without.

Even with cancelation, your statement applies. This proposal is entirely about convenience.

[AlicanC]

Are we absolutely sure that making this cancelable later won't be a breaking change

Yes, sort of.

Cool. 👍

[annevk]

Would TC39 not want this to be a static on Promise?

[domenic]

Would TC39 not want this to be a static on Promise?

I am pretty sure no. TC39 does not define an event loop or a notion of time; that is for the embedder. And using statics as a place to store utility methods is not a great pattern; it's forced by necessity in many cases, but in general statics should be reserved for things that vary among subclasses. You could argue this is one such thing, but I am not sure myself...

[jisaacks]

wait Doesn't look to be a reserved word and I think wait(500).then(x) reads rather well.

[benjamingr]

Hey, copying my reply from the duplicate (thanks for finding this Domenic):

wanderview: I'm somewhat ambivalent, but any such API probably also needs something equivalent to clearTimeout(). Maybe using AbortSignal/AbortController.

Sure, what if we allow passing an AbortController.signal as an optional second parameter?

await delay(3000, { signal: controller.signal} );

In a way similar to fetch?

Another interesting idea is a variant of setInterval that returns an async iterator, though we might not want to tie the two together.

for await(const time of interval(1000)) {
 // do something, `break` here to cancel (or `.return` on the iterator)
}