Vsevolod Tolstopyatov

Apart from the "reuse the same name" path, one of the other options I implicitly picked here is to start with `LowPriority...` and IDEA migration (in the next versions) with...

Yes, we can disrupt both `withTimeout` and `withTimeoutOrNull` simultaneously. On the one hand, it's indeed more sane and convenient to have them in the same package. On the other, it's...

>The details of how the IDE would be of help here are unclear to me. @dkhalanskyjb The key observation here was that IDE could do it in a less intrusive...

@alexvanyo that's a fresh line of thinking, thanks! `withTimeoutOrThrow` does not seem to be aligned with the overall naming scheme in Kotlin, because it's usually "the action OR throw if...

Tentatively, we have a winner! `withTimeoutOrThrow` is what we decided to use as our primary name for the prototype, so later I'll create a PR with that and with the...

Could you please elaborate on the problem you've faced?

The preliminary design decision is to deprecate `withTimeout` function with `@LowPriorityInOverloadResolution` and re-introduce it in the brand new package `kotlinx.coroutines.time` with the same name. The change is now blocked by...

The same applies to the cancellation before `withTimeout` even start (that is also observed in #1914). Historically, it was on par with `withContext` behaviour. Though the latter actively evolved (#962,...

It can be the case that the behaviour is too breaking and thus we should come up with a better name instead of silently shadowing the original signature. What concerns...

Here goes the discussion for the potential solution: https://github.com/Kotlin/kotlinx.coroutines/pull/4356