Hacker News Reader

Comment by numakerg | Hacker News Reader

Why couldn't they use a macro or a function?

EDIT: nvm. it says in TFA not the linked writeup

It cannot exist as a macro or function, because it transforms the code in ways they can’t. Macros can transform code, but the final output isn’t something representable in stable Rust, and so it would not compile post-expansion.

Would the macro case be addressed by also supporting a prefix keyword? The post that states macros can't work does not cover this. From what I can tell:

`foo.await!()` would just expand to `(await foo())`, and anyone could write their own `my_await!` macro that works similarly.

What's the benefit of this?

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 have to say, I don't consider

  "{} + {}".format!("foo", "bar")

to be better than

  format!("{} + {}", "foo", "bar")

Similarly with `result.try!()`, that does not look as nice to me as `result?`.

And postfix-macro syntax for await! would lead to code like

  let result = sendRequest().await!()?.getBody().await!()?.Root;

or if we used this for `try!()` as well then it would be

  let result = sendRequest().await!().try!().getBody().await!().try!().Root;

which just looks very noisy to me.

> to be better than

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.

That needs a postfix macro, which is a completely different feature that does not exist and may not ever exist.

Yeah, I was assuming postfix macro + prefix await was accepted, specifically to address the "it can't be a macro" argument in the initial post from boats.

Similarly, postfix keywords are not a thing that exist in rust, and await is the only accepted one.

The writeup mentioned that (await future)?; is undesirable because it disrupts the logical flow.

Could await be implemented as a prefix, with an additional macro?

awaits!(foo()) that expands to (await foo())

That ruins the chaining aspect.

I as well think there could be promise in someday exploring that space, but for the moment my enthusiasm for hypothetical postfix macros (which have yet to ever be formally proposed) is somewhat dampened by the realization that `foo.bar.qux.qaz.await!()` would need to expand to `await { foo.bar.qux.qaz }`, which makes me consider how uncomfortable such macros would be to parse (the saving grace of "normal" macro calls being the fact that both the reader and the compiler know exactly where the span of a macro begins and ends by looking merely at the balanced delimeters).

IMO, if the goal were ultimate language consistency then that would involve both adding an `await` keyword (with mandatory braces, like `if` and the others) and a postfix macro for the cases where it looks nicer. However, when considered by itself, 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.

(Though in honesty I think all these proposals are just trending towards justifying an F#-style pipeline operator.)

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

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

It seems there's a conflict between the logical flow of prefixes going right to left and postfixes going left to right. I wonder if there's any value (for other future languages) in having syntax to swap post and prefix for convenience

instead of (await doSomething()).somethingElse()

doSomething()@await.somethingElse()

That seems to be what this proposal is already working toward, eg with the discussion of also supporting .match.

keyword EXPR MAYBEBODY <=> EXPR.keyword MAYBEBODY

From the post:

> “Dot keyword:” In the previous post, a sketch was made of an idea in which certain keywords could be postfixed or infixed using the dot operator. This idea is only a sketch, and is not implied or guaranteed by the decision we’ve made here.

Ah, pity; I originally read it as "We aren't sure which - if any - keywords we want to do this to.".

Reply on news.ycombinator.com