# A final proposal for await syntax

**URL:** <https://internals.rust-lang.org/t/a-final-proposal-for-await-syntax/10021>\
**Category:** language design\
**Created:** [May 6, 2019, 2:36pm UTC](https://internals.rust-lang.org/t/a-final-proposal-for-await-syntax/10021 "2019-05-06T14:36:19Z")\
**Posts on this page:** 1\
**Showing post:** 123

<div class="post-metadata">

**Author:** ![BatmanAoD](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/batmanaod/32/1512_2.png) [@BatmanAoD](https://internals.rust-lang.org/u/BatmanAoD)\
**Post date:** [May 9, 2019, 7:48pm UTC](https://internals.rust-lang.org/t/a-final-proposal-for-await-syntax/10021/123 "2019-05-09T19:48:50Z")

</div>

I don't think the total number of comments is quite fair as a metric for how much "noise" is being generated without new arguments, because a lot of the comments are clearly not written with the intent of changing the team's mind.

I do, however, think that several points made so far seem fairly novel. I'll quote them here without introducing my opinions on whether they're valid or important; they're merely included because they weren't mentioned in the team's write-up or in the previous internals thread.

`.await` makes `+` non-commutative in some cases:

> [@mgeisler](#):
>
> ```rust
> let foo = some_expression.await;
> let bar = other_expression.await;
> return foo + bar;
> 
> ```
> 
> ....there is now an observable difference between the above program and this program:
> 
> ```rust
> let bar = other_expression.await;
> let foo = some_expression.await;
> return foo + bar;
> 
> ```

`.await()` should not be dismissed as "not a method":

> [@zackw](#):
>
> “no, really, _`await` is a method_ ” (and therefore postfix `.await()` is the most logical choice)

There is some circumstantial evidence that the community may feel strongly against this proposal, which may warrant additional outreach and research:

> [@tkaitchuck](#):
>
> There is a large divergence between where the Lang team ended up and what [a poll of readers of this form](https://internals.rust-lang.org/t/async-await-syntax-straw-poll/9954/39) preferred.

> [@whitfin](#):
>
> I think it’s worth polling the entire community on whether the plan should even change at all. The familiarity of `await foo()` should not be ignored, and I imagine a lot of people don’t care enough about `(await foo())?` to not have that familiarity.

Chaining may actually be detrimental to clarity:

> [@devsnek](#):
>
> Something that other languages have done is to purposely split up suspend points so that it is immediately clear to the reader and writer what the control flow of the code is.

`.await` may be detrimental to accessibility:

> [@phaylon](#):
>
> I don’t have a source for this, but I’d assume an additional prefix option can have advantages for screen reader usage as well? Then you go into the expression knowing there’s an await point.

There is a proposal for a generalized "postfix (or infix) keyword" syntax that would _not_ apply to `.await`:

> [@BatmanAoD](#):
>
> > @lordan
> > 
> > FWIW, if we consider the block as the first “argument”, and the expression/condition as integral to the keyword syntax, then it could also be a more Python-ish:
> > 
> > ```rust
> > { ... }.if expr else { ... }
> > 
> > ```
> 
> { ... }.while expr { ... }.loop { ... }.for var in expr
> 
> > ```rust
> > 
> > ```
> 
> To bring this tangent back to `await` , this looks like a good demonstration that “postfix keywords” are not a clearly defined concept with a single definite syntax/semantics, and in particular, it’s not clear how postfix `await` would fit into this scheme.

An argument _for_ `.await` that wasn't in the write-up:

> [@BrianMWest](#):
>
> postfix is best...[because] this is direction of eye movement to read an expression.

---

_[View the full topic](https://internals.rust-lang.org/t/a-final-proposal-for-await-syntax/10021)._