Would implicit `await` really be a bad idea?

This is explicit async, implicit await. Kotlin does their suspending functions this way.

Personally, I really like this style, because it accomplishes making async code look sync moreso than “implicit async, explicit await”, and makes the lazy versus eager-to-first-await versus started-in-background dimension of futures a non-issue.

If you want to delay the execution of async fn do_work(), you put it in a closure, just the same as if you were doing this synchronously: async || { do_work() }. If you want to execute it now (from the perspective of the execution context), you just call it: do_work().

But this doesn’t work for Rust. Why? Because we want the usage of async fn() -> T and fn() -> impl Future<T> to be the same.

In Kotlin and any “explicit async, implicit await” system, -> impl Future turns the equation around, making the async explicit (returning a closure, effectively), and requires a async fn await method call in an async context to run it.

3 Likes