Node: Should timers return a `then`able by default?

[benjamingr]

We can already util.promisify(setTimeout), but technically we can make timer objects contain a .then method (getter?) that could create a promise only when awaited allowing timers to be await without having to call util.promisify or sacrificing performance of timers for regular users.

• Do we like this?
• Do we think it's a good idea?

[AyushG3112]

Wouldn't this make cancelling timers tricky/not possible?

[benjamingr]

@AyushG3112 no, it would still return a timer object that you can clearInterval but it would also have a then method (getter) so it could be awaited.

We don't have a way to cancel promisified timers (but that's true anyway)

[AyushG3112]

@benjamingr I see. Another thing though, is that while this behaviour might make sense with setTimeout and setImmediate, what about setInterval?

If I am not wrong, promises are based on a concept of one and done, while setInterval is evalutated repeatedly till cancelled.

[benjamingr]

@AyushG3112 true, but setInterval isn't really convertable to a promise with util.promisify anyway.

setInterval could _in theory_ return a Symbol.asyncIterator though which means you'd be able to write code like:

for await(const clear of setInterval(1000) {
 // this runs every 1000ms
  break; // this clears the interval
}

Which would be cool (but isn't what I'm suggesting or discussing here)

[devsnek]

/cc @TimothyGu maybe whatwg could take a look at this?

[benjamingr]

@devsnek whatwg couldn't do this even if they wanted since their timers return numbers (well _technically_ they can, but I _seriously_ doubt they will).

Our timers return objects, so we're better able to do this.

[devsnek]

@benjamingr interesting, i wasn't aware of that. i like this idea lot but i will admit it makes me less welcoming of the idea if it can't be implemented in browsers

[jasnell]

Ping @Fishrock123 @addaleax

[medikoo]

This invites to use setTimeout in a way that's not compatible with other implementations (browsers)
Technically it's like adding some new thing to prototype of native object, but just in Node.js, that doesn't sound right.

As promises are ECMAScript already, I think this should rather be proposed to HTML standard, and not here.

[benjamingr]

@medikoo "Technically it's like adding some new thing to prototype of native object" - Node timers don't work the same way as browser timers already anyway - they already return objects (and not numbers).

As promises are ECMAScript already, I think this should rather be proposed to HTML standard, and not here.

Why? Let's consider just setImmediate, it is not specced in the DOM so there is no specified return value anyway - if that returns a promise that would be a nice win for anyone using async/await.

[benjamingr]

@medikoo worth noting that I generally agree that it's weird and am playing devil's advocate since we want to explore the possibility in order to solicit more feedback.

[medikoo]

Node timers don't work the same way as browser timers already anyway - they already return objects (and not numbers).

Indeed, but at this point it addresses Node.js specific use case (unferfing timers), which doesn't apply to browser environment. While here we're speaking about feature that's not env specific, but requested only for specific env. This at least to me sounds controversial as opens the door to incompatibility issues.

[Fishrock123]

This is possible to do - but of course canceling is a bit of a thorn and doesn't really work. So uh...
¯\_(ツ)_/¯

[TimothyGu]

I think the discussion has run its course in this issue as well.