It's not clear to me how an implicit await could be implemented; a counterexample that immediately comes to mind is any of the FutureExt combinators in the futu

It's not clear to me how an implicit await could be implemented; a counterexample that immediately comes to mind is any of the FutureExt combinators in the futures crate. The await keyword indicates the point at which something is done, but there could be multiple points in an expression that change the resulting type in the rest of the expression! Ex: my_fut().map(|x| x.y).then(other_async_thing) Awaiting after my_fut or .map() produces different types for resolving the rest of the expression. Also, I've often done things like binding a future in a scope and later awaiting it at different times (but always completing it). Making await implicit would make this impossible, unless a backdoor was kept in to indicate that you want an explicit await (which just comes down to the call site and shouldn't affect the Future implementation). Maybe these are moot points if futures must always complete, I haven't thought through the cases enough yet. Perhaps if futures can't be cancelled then FutureExt would not be necessary, and instead of passing `Future` types (into functions and elsewhere) we'd pass around `FnOnce() -> impl Future` types, or better yet `AsyncFnOnce()` since currently `FnOnce` suffers from not being able to specify a lifetime of an argument in the returned Future (which has hindered me many times).