A final proposal for await syntax

[RustyYato]

This has already been discussed before here

On why await shouldn't be a method

The discussion in Await Syntax Discussion Summary is centered around what that the Await Syntax Write Up calls the ​Error Handling Problem. In a fictive program that queries a database, one could imagine having code like the following: let conn = (await open_db("http://user@localhost:1234"))?; let stmt = (await prepare_statement(conn, "SELECT * FROM posts"))?; let posts = (await stmt.execute())?; for post in posts { /* ... */ } It is the use of parenthesis around await that is seen as problema…

Specifically the trait idea comes up here

On why await shouldn't be a method

This duality of await, behaving like a function call from the semantic outer perspective but not actually representing a call to an await function, prompted me to prefer syntaxes that logically bound the await to the call itself. The best syntax would be call-based and clearly associate the appearance of the async keyword with the call itself, and none of its arguments (neither the future, nor any argument position in the call to allow for extensions to generator arguments later). I don’t think …

Here is what I think is the best reason not to do it

On why await shouldn't be a method

But then that defeats the whole purpose of making it a trait method. The reason for making it a trait method is to make it less magic, because it’s just a normal method. So because it’s a normal method, people don’t need to learn anything new, and it doesn’t require new syntax, etc. But if you’re now saying, “well, it’s like a normal method, except not in these cases” people will wonder “why?” and then you have to explain that it’s not really a method, it’s actually special compiler magic. T…