4 ms·

Why couldn't they use a macro or a function? EDIT: nvm. it says in TFA not the linked writeup

steveklabnik 7y ago
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.
- staticassertion 7y ago
  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.
  - eridius 7y ago
    What's the benefit of this?
    - staticassertion 7y ago
      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.
      - eridius 7y ago
        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.
        staticassertion 7y ago
        > 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.
  - steveklabnik 7y ago
    That needs a postfix macro, which is a completely different feature that does not exist and may not ever exist.
    - staticassertion 7y ago
      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.
    - numakerg 7y ago
      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())
      - steveklabnik 7y ago
        That ruins the chaining aspect.
  - kibwen 7y ago
    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.)
    - staticassertion 7y ago
      > `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.
      - kibwen 7y ago
        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".
- numakerg 7y ago
  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()
  - a1369209993 7y ago
    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
    - steveklabnik 7y ago
      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.
      - a1369209993 7y ago
        Ah, pity; I originally read it as "We aren't sure which - if any - keywords we want to do this to.".

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.

staticassertion 7y ago
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.
- eridius 7y ago
  What's the benefit of this?
  - staticassertion 7y ago
    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.
    - eridius 7y ago
      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.
      - staticassertion 7y ago
        > 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.
- steveklabnik 7y ago
  That needs a postfix macro, which is a completely different feature that does not exist and may not ever exist.
  - staticassertion 7y ago
    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.
  - numakerg 7y ago
    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())
    - steveklabnik 7y ago
      That ruins the chaining aspect.
- kibwen 7y ago
  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.)
  - staticassertion 7y ago
    > `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.
    - kibwen 7y ago
      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".
numakerg 7y ago
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()
- a1369209993 7y ago
  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
  - steveklabnik 7y ago
    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.
    - a1369209993 7y ago
      Ah, pity; I originally read it as "We aren't sure which - if any - keywords we want to do this to.".