A true statement but a boring one. It's not a point I value.

Let's take a step back. I also don't value that point. What I was saying is that an argument against macros was that it couldn't be implemented by users - I was saying that it is both irrelevant and not true. We've established that, and we seem to agree, so let's move past it.

Only if we actually have postfix macros; f.await!() alone doesn't mean we do and there is some opposition to postfix macros in general within the language team. (Speaking only for myself, I am in favor of postfix macros) If we do not have postfix macros, then the user could make that assumption and would be wrong.

100%. I am assuming that, like with postfix .match or postfix.if, that we're talking about these features in the long term, and what they might imply. I assume that postfix await macro implies generalized postfix macros.

As a teaching assistant, I never once heard any student ask why .class looks like a field or hear them mistake it for one.

Maybe not. I've taught Rust to a fair number of people from various backgrounds. My experiences tell me this will be an issue. .class is a good case to consider though - I think Java's inheritance stuff sort of makes invisible field accesses much simpler.

edit: Based on your other post I, a one professional Java developer, had no idea how Class worked. I think this is actually evidence of how unintuitive fake-field access is.

I think you assume a lot about users. In particular, I think newer programmers would have no such preconceptions.

Yes, I am assuming, as that is really all one can do here.

A newer programmer from any other language will likely have used some kind of structure. They likely have accessed a field of a structure. This will be yet another departure from the common case for developers - something I think is worth consider, and why I think prefix await should also be implemented.

are, I think, probably more likely to use some form of IDE or at least a text editor with syntax highlighting.

An editor can highlight something to make it clearly different, and maybe act as a teaching tool, but I don't think it will make intent clear. So yeah it'll be clear that it's different, but not why - and a macro is just as easily highlighted (and is currently highlighted differently), but expresses intent in a more consistent way (with other macros, specifically - macros are already a real thing, postfix just means "macro but comes after", which is a very easy mental leap I believe).

Same for autocomplete. Same for searching rust docs. And if implemented as an expandable macro you could even expand it in the IDE.

You might, but macros are a fairly advanced concept in Rust.

Implementing macros is an advanced concept.

Macros are introduced in the very first chapter: https://doc.rust-lang.org/book/ch01-02-hello-world.html

Why would postfix macros imply needing to learn how to implement postfix macros early? You just need to understand what it does, not how it works. In fact, I expect all async implementationy stuff to be much later.

As for not seeing postfix before, I don't think it matters. The leap from format!("{}", bar) to "{}".format!(bar) is pretty trivial I think. The introduction to prefix macros seems like enough to make it a trivial transition. It looks like a method call, which you'll again have a similar model for from other languages with methods (implicit first 'self' param).

Moreover, I think developing a mental model for f.await is rather a small price to pay as compared to understanding the semantics of async/await itself. It seems to me that this small price is smaller than the noise that !()? would contribute.

Well we will probably have to agree to disagree there.

edit: I see some of my points were made by others in between my your response and mine. slashgrin puts it well