# Update on the await syntax after May 23 meeting

**URL:** <https://internals.rust-lang.org/t/update-on-the-await-syntax-after-may-23-meeting/10289>\
**Category:** Uncategorized\
**Created:** [May 28, 2019, 2:26pm UTC](https://internals.rust-lang.org/t/update-on-the-await-syntax-after-may-23-meeting/10289 "2019-05-28T14:26:49Z")\
**Posts on this page:** 1\
**Showing post:** 47

<div class="post-metadata">

**Author:** ![comex](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/comex/32/2587_2.png) [@comex](https://internals.rust-lang.org/u/comex)\
**Post date:** [June 5, 2019, 11:55pm UTC](https://internals.rust-lang.org/t/update-on-the-await-syntax-after-may-23-meeting/10289/47 "2019-06-05T23:55:10Z")

</div>

> [@gus](#):
>
> As far as I know, methods (or functions) that block until some condition changes are quite common, even in green-thread situations where the thread has to deschedule itself to allow another callstack to execute (or other exciting internal implementations). Given this, the await “semantics” of “an operation you can do to a `Future` to block and return the resolved value” seem so obviously applicable to a method-call that I don’t understand why we were even discussing other postfix alternatives 😉 What have I overlooked?

There was a long discussion about this and the "async-as-green-threads" analogy in this thread:

> [@On why await shouldn't be a method](https://internals.rust-lang.org/t/on-why-await-shouldnt-be-a-method/10010/2):
>
> The above is mostly based on my experience with async/await in Python where the new syntax was created after the community had experienced with co-routines implemented via yield. There it’s clear how the thread of control goes up and down the call stack. In case Rust async/await works completely differently, then I’ll be happy to be enlightened slight_smile

---

_[View the full topic](https://internals.rust-lang.org/t/update-on-the-await-syntax-after-may-23-meeting/10289)._