now, if the time is already over, I'd have to special case that. But most likely it is ok to just fire imediately

What is the use case where you would want an exception?

This is exactly the use case i was thinking about. Is there any thing wrong with this:

val deadline = System.currentTimeMillis() + timeout
// later 
    val current = System.currentTimeMillis()
    delay(deadline - current)

So, it would actually be:

while (true) {
    // do something
    val current = System.currentTimeMillis()
    if (current >= deadline) break
    delay(deadline - current) // not really -- does not make sense
}

Not really, does not work either with delay.

Interesting.... I need to think more about the way you'd use

delay

(in particular) with a computed time.

What your original use-case was? What was the larger picture of what you were doing?

I was thinking that in code like the example above:

val deadline = System.currentTimeMillis() + timeout
// do some work here 
    val current = System.currentTimeMillis()
    delay(deadline - current)

I'd rather have high CPU load then an exception which would most likely crash as kotlin does not enforce exception handling. Especially, as the 'some work' might be done before timeout expires on my machine. But not on some random production machine.

So, here comes a potential use case. Polling a server. Let's say you want to poll a server for fixed interval updates like this;

while (true) {
    val deadline = System.currentTimeMillis() + pollInterval
    // poll server and process result (e.g. update ui)
    val current = System.currentTimeMillis()
    delay(deadline - current)
}

If the server happens to be slow at a time, this would cause a crash or require special case handling. If delay(t) for t <= 0 would just return instead of throwing an exception it would just work. Or even better, if it would queue the continuation but without delay, it would just work, still be cancelable and not starve other coroutines.