Hacker News Reader

Comment by staticassertion | Hacker News Reader

> `foo.bar.qux.qaz.await!()` would need to expand to `await { foo.bar.qux.qaz }`

Interesting point, thank you. I hadn't seen this previously mentioned, and it's definitely a reasonable argument.

> there's no denying that `foo.await?.bar` appears nicer than `foo.await!()?.bar`, especially if there is no guarantee that postfix macros will ever become a thing.

Agreed, for sure. I'm honestly just very concerned about these features because I see them as stepping stones to others. The path from postfix macros seems much brigher than the path from postfix keywords.

I think I agree with you about an await block being a good idea.

Thanks for the response, I think this is the first meaningful response to the prefix await + postfix macro that I've read.

View on HN

No problem. :) I was actually in the same camp as you until, in the wake of boats' prior post on await syntax, I sat down and got well into writing an RFC for postfix macros until I stumbled upon the parsing concern and shelved it under the category of "not nearly as trivial as I thought it would be".

https://github.com/rust-lang/rfcs/pull/2442

Thanks, I haven't seen that RFC before, but reading it now it seems it would be insufficient to support this use case without also supporting `let x: impl Future`, since the RFC deliberately chooses to expand to a temporary binding for `self`.

It would also appear to be deficient for the same parsing reason I mentioned, i.e. that you need some way to tell whether `2 + 2.bar!()` should expand to `2 + bar!(2)` or `bar!(2 + 2)`; the RFC appears to choose the latter, whereas a hypothetical `await!()` would want the former. This problem is called out in the RFC:

"Rather than this minimal approach, we could define a full postfix macro system that allows processing the preceding expression without evaluation. This would require specifying how much of the preceding expression to process unevaluated, including chains of such macros. Furthermore, unlike existing macros, which wrap around the expression whose evaluation they modify, if a postfix macro could arbitrarily control the evaluation of the method chain it postfixed, such a macro could change the interpretation of an arbitrarily long expression that it appears at the end of, which has the potential to create significantly more confusion when reading the code."

As far as I can see, the RFC doesn’t mention precedence at all, but I think it’s safe to assume that it’s meant to be the same as method calls. So `2 + 2.bar!()` would expand into something like

    2 + {
        let _self = 2;
        bar!(_self)
    }

Reply on news.ycombinator.com