Update on the await syntax after May 23 meeting

Okay, but that's not what we were talking about. leaxoy asked for a solution, I gave them one.

That is incorrect. The await!(foo) syntax was originally experimented with in 2017.

Then in June 2018 it was officially added to nightly. That was over a year ago.

During this time, it has been used in many projects, including some very big projects. It has received extensive real world experience.

And the discussions about the .await syntax have been happening even before it was implemented on nightly, with its peak culminating in January 2019 (over 4 months ago).

This was not some quick rushed decision like you claim. It is the culmination of an incredible amount of time, thought, and hard work.

If you are worried about a lack of experience with .await, then please go to this thread and share your experience (as others have already done). But you need to do it before .await reaches beta (in about 5 weeks).

That's their choice. But I wasn't talking to you, I was talking to leaxoy, who clearly prefers prefix.


This doesn't practically work when there's more than one developer. Because reasonable teams use imperfect official syntax instead of introducing own bicycles.

Discussion, yes. I was talking specifically about the implementation. You can discuss syntax for years, but you can "feel it" only when you try it in real projects with real examples.

Real code is very different from toy examples:

  • real examples show how important is chaining (one of the largest arguments for the current syntax)
  • real examples use long function names
  • real examples are not tailored specifically for arguments

Three weeks was not enough for that.

Half of Rust language is syntax sugar (e. g. ? operator). That's fine.

lazy_static removes boilerplate.

wait!() removes nothing, just introduces complexity in the presence of stable .await.

1 Like

How long do you think it should take?

Yes, and if await! was stabilized, it would be completely reasonable.

The discussion was long, yes, but the new syntax in compiler was available for only 3 weeks.

Unfortunately, I did not find time to try it (except for toy examples). I could be wrong, but I suspect a lot of other people could not find time too.


People have until July 4th to experiment with the new syntax before it goes to beta.

So that means they have 8 weeks since the time the syntax was available on nightly. That's two months.

And that's ignoring the years of experience people have had with await!(foo). So it's 2 months just for the new syntax by itself.

Reasonable to you. Not to the Rust team. They have explained many times why they have chosen to not go that path. It is not up for discussion.

You have until July 4th. So get out there and build things!


Most features (except trivial) stabilized after several months after implementation. I think stabilizing a macro (or macro-like syntax) and waiting several months to stabilize underlying syntax would be ideal.

1 Like

The macro syntax, as well as postponing of the syntax decision, has already been very carefully considered, many times, and ultimately rejected.

.await was chosen as the final syntax (see blog posts and their discussions for reasons why).

Temporary await!() has been rejected to avoid fragmentation of syntaxes and to avoid potential migration later. We’ve had precedent with try!() -> ?. Many projects didn’t update, because they didn’t want to do the work, didn’t want cause merge-conflict-causing syntax churn. Some people don’t like the new syntax so they will use the old one forever, causing fragmentation.


To me, syntax is a fairly trivial part of the implementation, so I don’t understand why it warrants a long stabilization process.


What's the point of that? The syntax is final, the feedback would go straight to /dev/null.

So stabilizing await! would be right.



If it turns out that (during real world experiments) there are significant issues with .await, then they will seriously consider that.

They don't just ignore feedback. There's been many cases in the past where they have changed their mind. That's why they specifically made a thread asking for real world experience. You seem to have a very negative view of the Rust team, which I think is not deserved at all.

But you're clearly not interested in listening, so I'm not going to continue this conversation.


Things get re-considered when there’s new information presented. “I don’t like it”, “I like the macro syntax” are not a new information at this point (i.e. people already voiced these opinions and they have been included in making the current decision).


As a permanent solution, it should be rejected.

I think I have read all the posts and all the threads, and understand all arguments.

rustfmt could rewrite it.

BTW the problem you are describing seems to be nonexisting. I know only a handful of projects which still use try!.


Because I have done the work to submit dozens pull requests and update stackoverflow answers. There are projects that use the old syntax still.


Significant issues is a vague term. Any syntax works. Even no await works.

If new syntax would reveal the safety violation, they will obviously reconsider. But if it will just make code harder to read, it would be too late to stop that train.

As I said, only three weeks.

I think I'm listening, but anyway I'm sorry for wasting your time.


So what are you even trying to accomplish here?


The implementation is trivial, but the impact of the syntax choice is huge, so waiting a little longer wouldn't hurt.

1 Like

But wait for what? This discussion has already had thousands of comments, and for a while it’s been only the same few arguments going in circles.

Note that if you’ve just joined the discussion, it may seem rushed. But it’s been in the works for a long time.

In the meantime, there’s entire async ecosystem growing. Rust desperately needs to have a good async story, and it needs to stabilize on something.


For feedback on real projects, not speculations. A possible outcome could be:

  • people who prefer .await could find it actually not as good as they thought
  • people who don't like .await could decide that it is not too bad after all

Currently, projects don't use any async/await because it's not stable, and stable rust is a hard requirement for lots of projects.

And converting an experimental branch project to async/await is a large amount of non-automatable work people rarely can afford.

If the macro was stable, people could start actually using macro await, and at the same time can "try" experimental nightly syntax with a simple script which converts macros to any syntax.

  • We waited for async/await for years, waiting for a couple of releases longer wouldn't hurt
  • The macro could be stabilized first

This is a falsehood perpetuated by the layers and layers of hacks for the temporary await! on nightly.

await! cannot be a macro. This has nothing to do with code expansions or stability promises. It's because await is a keyword.

If await! were to be available on stable, it would be as a new kind of syntactical structure. The language team decided that the best option was "dot keyword" rather than any of the other options, including "keyword bang mandatory delimiters".


It can be a macro with a simple parser hack. Or simply wait! can be a macro. Any would do.