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