Explicit future construction, implicit await

[vorner]

How would implicit await help in any way against the function coloring? To that matter, how would implicit await help with all the unwrap_or_else being able to accept asynchronous closures? Their type and behaviour (eg. being able to bubble the NotReady up the stack and then being able to return back down) is inherently different, no matter if the syntax looks the same.

[tmccombs]

Leading on from the fact that, as specified in the RFC, async fn is an implementation detail that won’t leak into the public API is another point; support for migrating between async fn and manual Future implementations. By keeping async fn as an implementation detail that simply rewrites the function signature and body you can freely switch back and forth between using it or manually implementing your future. Hopefully this would mostly be used for migrating functions to async fn, but it could potentially be useful in cases like performing intricate performance optimisations since you have more control when doing a manual implementation.

YES! And since we don’t have async functions yet, that means in order for new async functions to really take advantage implicit awaits, most of the existing futures code needs to be migrated to async code as well. And that can’t be done in a backwards compatible way unless the names of the functions are changed, because calling an async function has different syntax than calling a function that returns impl Future.

I also think it is kind of weird that async functions act like functions in async context, but like a type in non-async contexts.

I do kind of like treating the async fn as a type definition rather than a function definition. But I think if we do go down that path, then:

1. It shouldn’t have fn in the definition syntax. I would prefer just having something like async foo(...) -> T instead of async fn foo(...) -> T.
2. It should define a tuple-like struct, where the constructor is the same name as the type. (But probably without pattern matching support)

[MajorBreakfast]

How would implicit await help in any way against the function coloring?

@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

[rpjohnst]

• Implicit await inherently requires some form of explicit non-await.

This is not a downside, it’s the point- this is what solves the confusion introduced by lazy futures. In fact, the main RFC already has explicit non-await, in the form of async blocks! It just doesn’t use it in as many places as this proposal.

Explicit await helps with detecting parallelization potential because it makes the suspension points visible.

Knowing the suspension points doesn’t really help, frankly. When parallelizing sync code, you wrap things into closures and pass them to some threading API. When parallelizing async code, you wrap things into async blocks and pass them to a combinator. It’s far more about data dependencies than about suspension points.

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.

This is not particularly relevant to this thread, as that can be changed before stabilization. Indeed, that is why this thread was created.

[MajorBreakfast]

This is not a downside, it’s the point- this is what solves the confusion introduced by lazy futures.

That’s why I listed it last It’s IMO an argument, just not very important

Knowing the suspension points doesn’t really help, frankly.

From my experience with JavaScript it does. When I see multiple awaits one after another I often decide to use Promise.all() and run them concurrently if the situation permits it.

This is not particularly relevant to this thread, as that can be changed before stabilization. Indeed, that is why this thread was created.

IMO async functions like the RFC defines them could simply be changed to use implicit await. IMO there is no need to change their API interface. The compiler knows which types are futures and would just introduce an implict await whenever it sees one. Places were we want to store the future in a variable (without awaiting it) could be annoated with noawait. It would be a breaking change, sure, but that’s no problem at this stage (before stabilization). The discussion should IMO be more focused around whether we actually want implicit await. That’s why I made the list with points why we should stick with explict await - because I’m not sold.

[rpjohnst]

The compiler knows which types are futures and would just introduce an implict await whenever it sees one.

This makes it impossible to hold onto a future without awaiting it, as you must when introducing concurrency. You went down that road earlier in this thread and found it to be a rather confusing mess.

Merely adding noawait is insufficient, and makes for an even bigger mess, because you’d need to annotate it every time you handle the future, not merely when you introduce it.

For example, it makes async blocks nonsensical, as I mentioned before:

let x = async { .. }; // OOPS, this is a future so it gets awaited...
let future = noawait async { .. } // ...so you have to do this instead!?

[MajorBreakfast]

@rpjohnst Constant nowait is probably a pain yeah. Your current proposal sidesteps this issue by distinguishing between async fn functions and ordinary functions that return a future. Here is how your proposal works conceptually:

• async fn functions return* an AwaitMeFuture
• ordinary functions return a DontAwaitMeFuture
• DontAwaitMeFutures can be awaited via await**
• AwaitMeFutures can be not-awaited via the ::new() notation***

*) async functions are defined as a struct, and a call inside an async fn to another async fn translates to another_fn::new().await()

**) DontAwaitMeFuture has an await() method that turns it into an AwaitMeFuture

***) It’s a method on the async fn struct

[rpjohnst]

I mean, okay, sure. But your insistence that async fns return some kind of future is the only thing making it so incredibly convoluted. There really is no distinction between an AwaitMeFuture and a DontAwaitMeFuture, because the call operation itself is what does the awaiting. It may construct a future somewhere, but that’s purely an implementation detail and not exposed to the user at all.

[rpjohnst]

Announcement: I have now completely revised the proposal! I think it’s got something for everyone- clearer motivation, simpler syntax, better examples, more thorough discussion of the alternatives, and links to relevant replies.

I would love for everyone who has questions or concerns to re-read it before charging ahead with further discussion, and also to consider their own responses thoroughly so we don’t re-tread the same ground.

[MajorBreakfast]

@rpjohnst Oh my bad. You said “I’m going to try to revise the proposal” once. We seldom agree on something, nevertheless I really try to carefully read everything that is said before I post. If you’ve mentioned that you updated the proposal before, I must have missed it and I’m sorry for that!

Edit: @rpjohnst’s has edited his post above to show that this is the announcement and he sent me a PM

[MajorBreakfast]

Your updated proposal lists this as a benefit:

For one instance, the Dart designers initially used “lazy” async functions with explicit await, but found them to be so confusing that they are switching to “eager” async functions in Dart 2. See /u/munificent’s comment on /r/rust for more.

According to the Dart 2 docs on asynchronous programming they’re still using explict await. They didn’t switch to implict await.

[CAD97]

async combinators async functions like await, select, and join serve as a “bridge” between normal async code and Future-based code, filling a similar role to threading APIs. Their signatures might look like this:

async fn await<F: Future>(future: F) -> F::Output { … }

async fn select<F, G, O>(f: F, g: G) -> O where F: Future<Output = O>, G: Future<Output = O> { … }

async fn join<F, G>(f: F, g: G) -> (F::Output, G::Output) where F: Future, G: Future { … }

All but await can be implemented simply by constructing the corresponding hand-written future and calling await on it. For example:

async fn join<F, G>(f: F, g: G) -> (F::Output, G::Output) where F: Future, G: Future { let join = Join { a: MaybeDone::NotYet(f), b: MaybeDone::NotYet(g) }; join.await() }

The body of await itself contains the usual polling loop. How this is accomplished is left unresolved for now- it may be a compiler intrinsic; we may provide async code with lower-level access to its task::Context along with the ability to yield; there may be another solution.

I think this would be clearer if you used futures::await to bridge between combinator impl Future and async context, rather than introducing async fn Future::await(self) magic without explaining it. You’ve got the one “magic” fn defined right there already which does what you want, don’t introduce two.

Then (Future).await() could be mentioned as a possible future (no pun intended) default fn that could be added to the trait to make awaiting easier.

But overall, this is now more consistent of a proposal, and I think I’m very slightly in favor of going this way, with all other things being equal (which they aren’t, of course).

rpjohnst:

For one instance, the Dart designers initially used “lazy” async functions with explicit await, but found them to be so confusing that they are switching to “eager” async functions in Dart 2. See /u/munificent’s comment on /r/rust for more.

According to the Dart 2 docs on asynchronous programming they’re still using explict await. They didn’t switch to implict await.

@rpjohnst didn’t say they did; they switched to “eager” futures which start executing as soon as you construct them (but that you still have to await to get the value out of):

Note for Dart 2: There is a slight breaking change for async in Dart 2. Instead of immediately suspending, async functions execute synchronously until the first await. In most cases, you won’t notice a change in behavior—as long as you await each time you call an async method, it won’t be an issue.

[rpjohnst]

I think this would be clearer if you used futures::await to bridge between combinator impl Future and async context, rather than introducing async fn Future::await(self) magic without explaining it.

Whoops, that is precisely what I intended to do. I’ve updated the post.

[MajorBreakfast]

@CAD97 It still does not apply as benefit. Rust’s async fns are lazy and this proposal also keeps it that way. It says so in “Motivation > Lazy-vs-eager confusion”.

[rpjohnst]

The point of that section is that this proposal is an alternative to eager futures, which aims to solve the same problems while preserving lazy semantics.

In other words, it’s the combination of explicit await and lazy futures that leads to problems. Remove one or the other and the confusion goes away.

(This reminds me of Rust’s “shared xor mutable”- you only need to remove one, it and it doesn’t have to be the same one every time.)

[MajorBreakfast]

In other words, it’s the combination of explicit await and lazy futures that leads to problems. Remove one or the other and the confusion goes away.

You mean when you forget to call await? Then, either the types don’t match or it is caught by the “unused variables” lint introducing a “unused must use” warning for futures (like it exists for Result today)

[CAD97]

Mitigations In cases where the caller is already !Unpin (i.e. always, at first), this distinction only matters if the caller is also using the pattern for concurrency, making the additional await call irrelvant. For the cases when the caller does not need concurrency, we can introduce some minor derive-able boilerplate to make things easier:

async fn foo_async(arg1: &str, arg2: &str) -> usize { foo(arg1, arg2).await() }

You probably wanted to change this one to futures::await as well.

(Gah, Discourse’s quote feature is messing up formatting for me on mobile…)

[yasammez]

Since the RFC was posted I tried to follow it all, but especially this thread always seems to move faster than I can keep up with; what a great, engaging community this is!

There has been a lot of talking about the Kotlin language in here. However, a comparison with Go could also shed some light on it. Disclaimer: I never used Go and all this is hearsay, but as far as I recall, in Go every statement is a possible suspension point, because everything can always yield to the Go green threading executor thingy. In practice this is indistinguishable from a preempted world in which an interrupt can move control over the thread from you after every CPU instruction, i.e. OS scheduling. This may be fine for Go (and Kotlin which comes with a default CPU pool?) which was designed to do one thing and do it well and solved the function colouring problem with a sledgehammer. Rust on the other hand has different design goals and ditched green threading a long time ago (which made me very happy). People are building kernels and other very low-level stuff in Rust. In a world where there may be no executor, no tokio reactor, no runtime support at all; maybe the futures will be polled, maybe they will be spawned on some hand-rolled state machine, who knows? Thus I am all for the “make interesting things explicit” way. My only wish was that async fns could anounce their impl Future in their visible signature; I understand from the RFC discussion that this is problematic together with lifetime elision, but I think it would have made the case clearer here, because then an async fn can just be read as a function which you can call to get exactly what it says on the tin, an impl Future, which you can then await at your leisure.

When the proposal for an @-sigil was first made, my guts hated it, but as I absorb more of the discussion, it looks nicer to me each day. So a +1 to that as well from me.

[rpjohnst]

You mean when you forget to call await? Then, either the types don’t match or it is caught by the “unused variables” lint

How, then, did anyone ever get confused using Dart 1?

[mark-i-m]

The illustration here is that just because it looks like it works, in reality that doesn’t always mean that it works as expected. I am under the impression that explicit await would have prevented this kind of condition (or at least been a good indicator of something gone awry) because it is nonsensical to await a synchronous function (like the blocking client API in pika). And if you know you are blocking a single threaded application, then the locality of the bug becomes more apparent.

I didn’t quite understand this point. IIUC, you are saying that if await was explicit, you would have tried to await!(pika_client()) and gotten an error that pika_client is not async. Is that correct?

---

The simplest way to get a value from an impl Future is the await function, the async equivalent of block_on.

Sorry, I didn’t quite understand the distinction between block_on and await.

async fn do_work() { .. }

async fn do_work_with_timeout() {
    let work = async { do_work() };

    let when = Instant::now() + Duration::from_millis(100);
    let timeout = Delay::new(when);

    futures::select(work, timeout);
}

To be clear, the actual work of do_work does not start until the select, right? So if I wanted to start the work earlier and concurrently do some other computation I would do something like this:

async fn do_work() { .. } // assume the work happens on thread B

async fn do_work_with_timeout() {
    let work = async { do_work() };
    let work = async { futures::await(work) }; // concurrently start `work` on B

    my_sync_function(); // do some computation synchronously on this thread

    let when = Instant::now() + Duration::from_millis(100);
    let timeout = Delay::new(when);

    futures::select(work, timeout);
}

Is that correct?

In an async context, the call some_async_fn(a, b, c) is expanded to this:

Is this supposed to say in a sync context (i.e. not in an async block/fn/closure)? Or does it intentionally mean that in an async context we will block until the Future is resolved?

A common objection to this proposal is that it hides async code’s suspension points, making them look like normal function calls. This is important, they argue, because suspension points might allow another task to violate some invariant unexpectedly.

However, we already have an un-annotated operation that can do the same thing: a normal synchronous function call!

I still don’t completely buy this argument. I realize that it’s possible for a function to do arbitrary crazy stuff in theory, but in practice I don’t usually expect a function to do arbitrary stuff in the middle without that being documented. On the other hand, in concurrent code I very much expect random stuff to happen in the middle of a function call (say, on another thread).