Except for the fact that this behaviour is surprising.
> you should be checking your input against the range that's valid. Your sample code simply doesn't do that, and that's why there's a bug.
Indeed, so why doesn't setTimeout internally do that?
Given that `setTimeout` is a part of JavaScript's ancient reptilian brain, I wouldn't be surprised it doesn't do those checks just because there's some silly compatibility requirement still lingering and no one in the committees is brave enough to make a breaking change.
(And then, what should setTimeout do if delay is NaN? Do nothing? Call immediately? Throw an exception? Personally I'd prefer it to throw, but I don't think there's any single undeniably correct answer.)
Given the trend to move away from the callbacks, I wonder why there is no `async function sleep(delay)` in the language, that would be free to sort this out nicely without having to be compatible with stuff from '90s. Or something like that.
The browser devs have decided it's acceptable to change the behaviour of setTimeout in some situations.
https://developer.chrome.com/blog/timer-throttling-in-chrome...