Does `await` truly need fixing?

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

3 Likes

It did not, it explicitly left the syntax undecided.

7 Likes

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

1 Like

Not at all. The future.await syntax idea was raised (invented?) by @scottmcm in 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.

7 Likes

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

4 Likes

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.

4 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.