Explicit future construction, implicit await

language design
47

@vorner What they mean is that calling functions of both "colors" (sync and async) looks the same in async functions with implicit await.

I'm now in favor of explicit await (again) and here's why:

Ordered by importance (in my opinion), most important first

  • Explicit await helps with "the learning curve when ramping up newcomers to an existing codebase" by showing new developers which functions are asynchronous without requiring a look at their definitions. (argument by @parasyte)
  • Async functions have by their nature different execution characteristics and explicit await makes it obvious where we call them. @vorner's comment goes into great detail about this. He points out various problems he sees and says explicit await is valuable "when doing code review". @parasyte says that he was once hunting for a bug in a python project with implicit await and he thinks that it could either "have prevented this kind of condition" or failing that "been a good indicator of something gone awry".
  • Explicit await helps with detecting parallelization potential because it makes the suspension points visible.
  • It's how the system currently works (await!() macro). Sticking with explicit await makes shipping async functions with Rust 2018 edition more likely.
  • Implicit await inherently requires some form of explicit non-await. So, it just changes what we annotate.

Edit (1 day later): Additionally all implementations of implicit await that were proposed so far:

  • Need a different notation for the initialization pattern (What's that?)
  • Are a more complex addition to the language than the solution of the RFC

So far there has been a lot of discussion about the type of async functions. The RFC has now entered final comment period. It defines async functions as functions that return a type with impl Future.

BTW @MajorBreakfast2 is now gone again :smile:

2 Likes