Postfix macros are a great feature in general, if accepted later. This would open the door for them, and you'd get things like:
"{} + {}".format!("foo", "bar")
and other niceties. It would have also solved the try macro's issues, like:
result.try!()
etc. There are plenty of use cases where postfix macros are awesome.
Macros are already a known control flow mechanism, so a postfix macro should be very easy for both new and old rust users to understand.
It isn't a fake field access, so it's already a step ahead of the competition.
And you get prefix await, which every other language uses, and this addresses the singular argument against macros being used (which is that the macro could not be implemented by users), though I never felt that it was a strong argument anyway.
I don't want to go back and forth discussing it. It isn't happening. I was just curious if the prefix await would have addressed that one argument.
I do, especially in terms of writing. It's quite annoying to 'wrap' things, in my opinion. This is why chaining is desired to begin with - people consistently prefer to append new code than to wrap.
> Similarly with `result.try!()`, that does not look as nice to me as `result?`.
I also prefer ?. 'try' is so common it's worth optimizing down to a single character.
My point is to compare to the prefix try, not the question mark, as a motivator for where postfix macros are a reasonable concept.
> let result = sendRequest().await!()?.getBody().await!()?.Root;
It's an additional 3 character per 'await' vs the other syntax, which I think is fine - a small price to pay for a syntax that makes sense. If await were so common, I would once against think a sigil is the way to go, but I don't believe that await justifies that level of optimization at this point.
