await <expression> is the correct syntax for because it is consistent with existing operators that control flow of your code.
When I look at it, I see that my code will perform something special with expression, like match or return.
And as all of these keyword operators it shall return expression.
In case of match it returns expression that returned by each branch of pattern, while await will return Output of Future
In short, awat <expression> which was initial plan in async/await RFC is natural syntax.
What brings .await aside from being work-around for error handling ergonomics?
Confusion, community dislike and embarrassment to language.
You can argue that we all can get used to it and stop complaining, but in actuality the .await syntax brings nothing to the table aside from easy way to fix some minor problem.
Please do tell me what are benefits of .await syntax comparing to natural await <expression>
There was no RFC to adopt .await, it is just suddenly someone decided that Rust should have new weird syntax which is not the same as ?, as .await is not only unfamiliar but it is also contradicting to existing language syntax.
P.s. I must highlight that initial RFC proposed as future await <expression>, not .await, deciding lightly on .await is not something that should be done, considering community expectations from RFC
It might leave final syntax undecided, but it is pretty much can be assumed as RFC treats it as control flow expression, and the only reason it was left undecided it problem of ?
I read that section as here our idea await <expression> but we need to think about ? so might we modify it a bit like edition brackets and etc.
In any case, adoption of syntax should require RFC process
Not at all. The future.await syntax idea was raised (invented?) by @scottmcmin the RFC.
As you can see, I was initially skeptical of postfix .await and thought that it should be prefix. Scott provided sound arguments then and I have ever since held postfix in high regard.
His reasoning is at best subjective, there is nothing sound about considering only one use case.
The only reasoning for it is to imitate chaining of methods, but then what will become of read-ability?
await is not some simple method invocation, it actually changes the flow of program.
I can imagine having few chains of async ops, but I do not believe it would justified something like x.foo().await.bar().await.qa or even .await()
The language syntax should be consistent, and not favoring someoneās personal taste.
I like making convenient builders that would allow me to configure something via long chain of method invocations, but I wouldnāt do something like that for multiple async operations.
Instead Iād prefer something like
let foo = await x.foo();
let bar = await foo.bar();
bar.qa
You can argue that I can go by with .await, but await <expression> is more natural in Rust as continue, return and other keyword operators
await should follow these examples, not ?
P.s. in the end the idea might be raised, but it should be formalized as RFC instead of making it a big surprise to community.
P.s.s Iām pretty sure Iām not alone who thinks of .await as mistake too
Iād like to point out that while there hasnāt been a targeted RFC for await syntax in the RFC repo (which is consistent with the RFC process), there has been and is currently a Request For Comments everywhere else.
Starting (in major effect) with the GitHub issue in January and continuing to withoutboatsās blog announcement and the irlo threads (all of which were advertised on Reddit as well), there have been ample opportunities and Requests For Comments.
The async RFC left the await syntax to be decided as part of stabilization. These multiple threads have requested community comments on the await syntax to inform the lang teamās decision. All putting it in the RFC repository would do is formalize the comments already considered and invite another avenue for people to reintroduce the same exact āopinionā argument (when what the lang team needs to make an objective decision are actual new data to work with).
The system isnāt perfect; no system is perfect. Any bikeshed color will disappoint someone. Itās almost too easy to hold an opinion. But I think in terms of information gathering weāre at a local maximum thatād take more effort to reach a higher one than weāre willing to pay in delays to the MVP shipping of the feature.