Update on the await syntax after May 23 meeting

[Pauan]

@stepancheg

I read the source code of other libraries a lot. Sometimes I copy-paste the code. Sometimes I work with my colleagues how may find the idea of introducing a macro just to wrap the keyword not very smart.

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

@stepancheg

It was just three weeks between prototype committed to rust repo and final decision.

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).

@stepancheg

But people who prefer single code style across the code base will use .await syntax even if they prefer some other syntax.

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

[stepancheg]

@RustyYato

They could just as easily use wait!(...) everywhere instead of .await

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

@RustyYato

This is blatantly false, there was extensive discussion since the initial RFC for async/await.

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.

@RustyYato

Actually, you can’t really extend Rust with macros, you can remove boiler-plate

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.

[RustyYato]

@stepancheg

Three weeks was not enough for that.

How long do you think it should take?

[stepancheg]

@Pauan

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

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

@Pauan

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).

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

@Pauan

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).

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.

[Pauan]

@stepancheg

Three weeks was not enough for that.

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.

@stepancheg

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

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.

@stepancheg

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.

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

[stepancheg]

@RustyYato

How long do you think it should take?

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.

[kornel]

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.

[RustyYato]

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

[stepancheg]

@Pauan

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

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

@Pauan

And that’s ignoring the years of experience people have had with await!(foo) .

So stabilizing await! would be right.

@Pauan

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.

Sure.

[Pauan]

@stepancheg

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

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.

[kornel]

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).

[stepancheg]

@kornel

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

As a permanent solution, it should be rejected.

@kornel

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

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

@kornel

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 don’t want to do the work, don’t want merge-conflict-causing syntax churn. Some people don’t like the new syntax so they will use the old one forever, causing fragmentation.

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!.

[kornel]

@stepancheg

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.

[stepancheg]

@Pauan

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

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.

@Pauan

That’s why they specifically made a thread asking for real world experience.

As I said, only three weeks.

@Pauan

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

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

[notriddle]

@stepancheg

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

So what are you even trying to accomplish here?

[stepancheg]

@RustyYato

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

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

[kornel]

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.

[stepancheg]

@kornel

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.

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.

@kornel

Rust desperately needs to have a good async story, and it needs to stabilize on something.

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

[CAD97]

@stepancheg

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".

[stepancheg]

@CAD97

await! cannot be a macro

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