On why await shouldn't be a method

[Pauan]

@zackw

What I care about is the notation and the surface implications of the notation.

Oh, well that's an entirely different argument, then! I was only arguing against trait methods.

I don't have a problem with people who prefer the .await() syntax.

@zackw

My argument has always been that I think f.await() is more likely than f.await to indicate, to people who are reading async functions, the correct mental model for how it behaves. Namely: autoderef applies; it invokes code that depends on the concrete dynamic type of f ; it may perform an arbitrarily lengthy operation before returning to the caller; and it does not introduce a branch into the surface control flow.

But none of that is true:

• .await does not auto-deref, and .await() wouldn't auto-deref either.

• Field syntax can run arbitrary user code and can block.

• .await does introduce a branch into the surface control flow.

  It must do this because the async fn returns a Future, and the Future's poll method must return to the Executor. It cannot synchronously block.

  Thus, when a .await happens in the code, there is an implicit return (just like ?), and an implicit loop.

It's fine to prefer the .await() syntax, but you should do it for the right reasons, not based on misinformation.

@zackw

It creates a branch in the state machine, but this is invisible in the surface control flow.

How is that any different from saying that ? creates a return which is invisible to the surface control flow? In both cases they're creating implicit returns.

@zackw

So I don’t see “the await operation can block” as a valid argument for “the await operation shouldn’t look like a method call”.

To be clear, the "blocking" that an .await does is very different from the normal synchronous blocking (e.g. synchronous I/O).

It's different both from a mental standpoint, and also very different from an implementation standpoint.

Rust likes to make the programmer aware of low-level details, so of course Rust makes a distinction between synchronous and asynchronous blocking. Just like how it makes a distinction between the stack and heap.

@zackw

Have you or some other team member written out an explanation of why you do see it as unnecessary noise? I don’t recall seeing that in withoutboats’ blog post. It could have gone by in one of these threads and I missed it; if so I would appreciate a pointer.

Niko wrote a couple very good summary posts in the "A final proposal for await syntax" thread:

A final proposal for await syntax

tradeoffs of postfix dot notations I’ve been reading this thread. I want to try and leave a few thoughts. I’m going to write two comments in short succession. This first one aims to give a more detailed look at the various “postfix options” that are based on .. It begins by summarizing the key points around each option, and then gives me “personal narrative” that explains where I personally fall. I want to emphasize that I am explicitly not considering future generalizations in this post. I’ll …

A final proposal for await syntax

In my previous comment, I looked at the “dot syntax” options and tried to discuss them. In this comment, I want to try and consider “the future”. Again, I apologize for the length. If you prefer, this comment is also available on HackMd. I’ve seen a few folks make an argument that roughly says: We should just pick await foo for now – then we might consider various generalizations going forward. The reasoning is that there are a number of options that generalize await foo to permit smoother …

There's also a lot of other information floating around, but it's mostly in the actual discussion threads (which happened months ago, and covered essentially every possible option, and all the pros and cons of every option):

Tracking issue for async/await (RFC 2394)

Resolve `await` syntax