It’s very easy to write a macro:
macro_rules! wait {
($e:expr) => {
$e.await
}
}
Now you can use wait!(foo) instead of foo.await
There’s even a crate which does this for you.
There’s also a crate which adds in implicit await (if you prefer that).
Sure. But it’s very hard to write a macro which will be used by code not written by you. E. g. in third-party libraries.
You didn’t get the point. A macro could be used to postpone syntax decision.
If .await syntax is final, then the macro is pointless.
I don’t understand your point. The macros are used exclusively inside of your code (specifically inside your async functions).
It has absolutely no effect on anybody who is using your library, because it’s an implementation detail.
In other words, there’s literally no difference between using wait!(foo) and foo.await (other than the syntax)
No, that was not their point. They asked for a user-based way to use prefix await, and I gave them one. They mentioned nothing about the official decision.
The decision has been made, it was carefully considered, and it will not be postponed. It’s over.
No, it isn’t pointless. People who prefer the wait!(foo) syntax can use it instead of foo.await.
That’s the beautiful thing about macros: you can use them to change Rust to fit your personal preferences.
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.
It was just three weeks between prototype committed to rust repo and final decision. Other changes in Rust, especially major like this, bake for months in unstable. It was not carefully considered.
Sure.
But people who prefer single code style across the code base will use .await syntax even if they prefer some other syntax.
This is not what macros are for. Macros are for extending rust, not for having a different syntax of already existing language constructs.
They could just as easily use wait!(...) everywhere instead of .await
This is blatantly false, there was extensive discussion since the initial RFC for async/await. If you were late and only heard of this via the Rust Internals post a few weeks ago that’s too bad (Rust cannot wait for literally everyone’s opinion because new people come everyday), but you cannot say that there wasn’t enough discussion.
edit: see @Pauan’s comment below for a brief history of async/await
Actually, you can’t really extend Rust with macros, you can remove boiler-plate (think lazy_static) and make the syntax nicer (subjective, thing DSLs), but you can’t extend Rust’s capabilities.
You could remove macros from Rust entirely and not lose anything other than some efficiency where the macro wraps some nightly feature, but every non-std macro can be removed without restricting the language. Now, it would be significantly more painful to write Rust if you remove macros (because of lots of boilerplate for things like lazy_static or similar), but you could do it.
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:
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.
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.
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.
Sure.
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?