I come from the Node world (I'm not really familiar with Rust at all), where the syntax is "await foo()", and to be honest I really like the .await syntax. First, as others have stated it makes the operator precedence clearer in my opinion. But more importantly, in my brain it makes it feel like await is a "member operator" of Promises (or I guess futures in the Rust case), so I can think "Function returns a promise, and then "calling" await on it yields and then returns the resolved object when done".

My understanding of the issue (which is shallow at best) is that it's a battle between a prefixing keyword or sigil which has the problem of causing the reader to scan back and forth in the statement when chaining multiple items, which sucks), or a postfixing keyword or sigil, with dot notation for a keyword to help parsing (and everyone seems to dislike the overloading of the dot notation for this). Ignoring sigils, I think the chosen solution is the lesser of two evils.

That said, I think a postfixing sigil would have been much better. It seems an important enough thing to denote that a bit of special syntax is called for, and the more unique the better.

For example, on C#, I sometimes have to do:

  var value = (await (await startRequest()).GetBody()).Root;

While the Rust syntax would make this a little more clear, I do not think it is a dealbreaker.

For ease of comparison, here's how that would look with syntax akin to Rust's choice:

    var value = startRequest().await.getBody().await.Root;

Assuming these are failable actions then this would probably end up looking like

  var value = startRequest.await?.getBody().await?.Root;

While we are doing comparisons, here is the Promise version:

    startRequest()
        .then(req => req.getBody())
        .then(body => { value = body.Root })

Please don't do that. I had to look several times to rewrite it as

    var temp1 = await StartRequest();
    var temp2 = await temp1.GetBody();
    var value = temp2.Root;

which is instantly grokked.

This is a great example of why syntax and semantics can't be separated. This works great in GC'd languages, but in Rust, these two things may not be equivalent. With the distinction between owned and temporary values, this may change the lifetime of what stuff is in scope and when. This is reduced a bit with non-lexical lifetimes, but it's not, strictly speaking, actually equivalent.

I think this is a good example to show people who are on the fence about postfix then. I haven't felt strongly about postfix, but this is an eye opener for me.

Yeah, I think the trick is that the theory and practice might be the same. And usually, it's the other way around; spreading it out makes it work, whereas it may not otherwise. For example:

    fn main() {
        let world = gives_string().split(" ").next();
        
        println!("{:?}", world);
    }
    
    fn gives_string() -> String {
        String::from("hello world")
    }

This will fail because the String is temporary, and we're trying to get a reference to it (via split), and so it would be deallocated at the end of the line, being a use-after-free. This, however, compiles:

    fn main() {
        let world = gives_string();
        let world = world.split(" ").next();
        
        println!("{:?}", world);
    }
    
    fn gives_string() -> String {
        String::from("hello world")
    }

We're shadowing 'world', but the underlying String now lives to the end of main, so everything works, no more use-after free.

I think before I'd want a good real-world example of where doing the multi-line thing goes wrong before I'd want to make an argument that this is why postfix is better.

This has surprised me on occasion. Shouldn't the compiler be smart enough to figure out how long to keep it around for, instead of failing to compile?

The compiler is smart enough to deduce lifetimes — that’s why it can throw a compile error — but fixing them (auto-keeping temporaries) might introduce extra memory consumption/leaks that the programmer did not intend. Requiring the programmer to explicitly assign a temporary to a variable makes the programmer’s intent more clear.

A comparison: in C++, the behavior of auto-extending the lifetime of const references to temporaries (but not non-const references) is considered a wart in the language design. (Really, you should just assign a temporary to a value because the compiler can elide the copy. : https://abseil.io/tips/101 .)

One could argue that the compiler could transform this for you. But systems languages are also about control. For someone versed in the way things are supposed to work, an owned value living longer than it should is surprising.

Tradeoffs, tradeoffs.

It's a better case for showing how to use .map().

I totally get where you coming from, and even in non GC'd languages such as C++ lifetimes are extended (or not...) when you break down expression.

However, I also strongly perfer to give these subexpressions names. That tremendously helps when debugging, logging, or just discussing the code with colleagues. In fact, these subexpressions do exist and they are a certain unit to reason about, especially when the program is not doing what it should. In these cases (and not only these) you really want to give them a canonical name and not only "line 42".

Maybe there should be a syntactical equivalent for named subexpressions.

I do too, which is why I preferred prefix await.

There are a few different ways I feel about this at the same time:

- On the one hand, I agree that "interesting" operations really should be on their own lines. I think I'm going to strongly prefer to keep it to one `await` per line for the foreseeable future.

- On the other hand, I know that many programmers will cram a lot of operations into one line if they can, and when that inevitably happens it would be nice for it to be readable.

- And maybe in the long run, it's possible that a big, mature async ecosystem might make a lot of these operations so commonplace that they aren't "interesting" anymore. Maybe in that world we'll be glad to have a syntax that makes it easy to chain things together.

This is to my eyes far more cluttered and confusing than:

    var value = StartRequest().await.GetBody().await.Root;

Or if you prefer multiline:

    var value = StartRequest().await.
                GetBody().await.
                Root;

this makes my eyes bleed

Why?

Because you have to read from the inside-out instead of left to right or right to left, most likely.

> That said, I think a postfixing sigil would he been much better. It seems an important enough thing to denote that a bit of special syntax is called for

They can still introduce a sigil later, if the .await syntax turns out to be common enough in code that the long keyword hinders readability. This is how it was done with the try!(...) feature, which now uses ? as a sigil. But as the article points out, pure sigils are a scarce resource so .await might well be the best way to go anyway.

Yeah this argument doesn't hold water for me either. Learning new notation versus learning a special-cased exception to the normal semantics of an existing piece of notation feel like really comparable levels of cognitive overhead to me.

I don't think this is necessarily a bad choice overall but I find this particular line of reasoning a bit specious.

Await is a keyword, syntax highlighters will most likely paint it differently.

Speaking as a member of the Rust language team: we specifically evaluated all syntax proposals on the assumption that many people may end up reading them without syntax highlighting. People read code in many places outside of a programmer's text editor or a code-highlighting web page, including logs, diffs, and emails.

Hopefully you didn't make a decision based on some exception use case.

The parent commenter does not suggest that this syntax was chosen based on assuming users don't have syntax highlighting, only that they did take into consideration that not all users have syntax highlighting.

I understand that, but how much into consideration? Let's just make up some numbers, if 1% of reading of Rust code takes place in environments without code highlight, then it should have been 1% of the consideration. Is that the case?

I don't think you should weight it like that. If you have multiple proposed syntaxes, and both are equally effective with code highlighting but one is moderately ineffective without highlighting, then it makes sense that you should go for the latter. The weighting controls how much of an effectivity loss in the code highlighting case you would be willing to trade off against effectivity improvements in the other case.

It sounds like you're agreeing with me. If two options are indeed essentially equal on all fronts, then one minor use case can be enough to push it towards a winner.

I find the syntax highlighting argument odd. It's like arguing a road surface is acceptable because the dangerous conditions it causes are mitigated by traction control.

I find the don't-consider-syntax-highlighting-at-all argument odd. It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference.

(Analogies here suck. Instead, consider that the vast majority of programmers read code that has been syntax highlighted. To completely discount that experience at all would be odd.)

> It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference.

There is a reason that we have three separate lights still instead of one (that is, there's more reasons than just inertia), and that's because some people can't tell the color differences. Specifically, my father can't easily tell the color difference between green and yellow. I've had friends that also had this problem. It's not uncommon.

> To completely discount that experience at all would be odd

I'm not saying to discount it entirely, but consider it in context. I think it's a somewhat elitist argument, because it assumes everyone both has syntax highlighting set up and that their highlighting will work as well as yours.

I accept that syntax highlighting helps, and is a positive if it can be applied well to a solution, I just think it's far from sufficient.

Put another way, an optional, environment specific configuration setting is not sufficient to offset the negative aspects of an official language level feature, if we're able to weigh things prior to being implemented.

If Rust were required (or even officially expected) to be written in an environment where that was always available and easily configurable, I would think different. E.g. if we're talking about Visual Basic, or Smalltalk with it's IDE (IIRC, not that I have experience with it), then I would think different, but as long as the Rust compiler is expected to take in files of text and not some rich format that includes extra metadata, I don't think language design choices should weigh non-text considerations too heavily.

> but consider it in context

Which is exactly what has been done. So I don't understand what you're complaining about. The rest of your comment is a giant straw man. I've never heard of or seen implied that anyone in any decision making position in the Rust project is "assuming everyone has syntax highlighting set up."

When you make ridiculous assumptions about the decision procedures of other people, then it's easy to derive ridiculous conclusions. But reality is always more nuanced than that: https://news.ycombinator.com/item?id=20031706

I never made an argument about the Rust project assuming that. I'm talking about people using the availability syntax highlighting to dismiss a negative aspect of a possible choice. I was making that argument in general, but spurred by a specific comment here. I used the context of the Rust community discussion as an example, but never did I assume Rust was using this as a metric (just noting that it has been put forth in arguments from the community).

My argument at this point (as illustrated by the Rust discussion) is simply:

- Rust/rustc takes in unicode text as source

- Since it has no knowledge at the source level of syntax highlighting, using that to mitigate the downside of a language level syntax for a feature is problematic

- We as the public should keep that in mind when discussing the relative merits of one possible implementation or another of a feature.

That's not denigrating or assuming Rust actually did this, it's a note about the community level discussion and how some people approached it, as evidenced by a very specific comment in this thread, and how I thought it had some problems when applied to language level decisions.

All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently." Which is a perfectly cromulent thing to say, and isn't contradictory of anything you're saying. Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently," then you'd have a point.

I guess I'm just so tired of folks piping up with the "not everyone uses syntax highlighting" crap almost every single time anyone even hints at the notion that syntax highlighting can help a particular piece of syntax. I guess you're probably tired of the opposite.

> All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently."

Which was in response to someone's criticism regarding .await notation that "it's easy to not even be aware it exists and think a struct had a member called await instead..."

> Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently,"

That's how I interpreted it based on it being a reply to that exact criticism.

> I guess I'm just so tired of folks piping up with the "not everyone uses syntax highlighting" crap almost every single time anyone even hints at the notion that syntax highlighting can help a particular piece of syntax. I guess you're probably tired of the opposite.

I understand! As I noted earlier, I'm for syntax highlighting in general. If I was forced to never use syntax highlighting for programming again, I might consider a career change and only programming on things I really care about instead of to pay the bills. It's because of this extreme distaste for how annoying it is without syntax highlighting that I'm extremely adverse to making it any worse than it already is, because there's been a few times where I've been forced to endure it.

For the record, I'm fine with the currently accepted await syntax. Out of what I would consider the ideal outcome to me (postfixing special sigil/character), it's at least postfixed. While prefixing await looks prettier in the singular case, it makes any sort of chaining cumbersome and error prone to parse out by eye, and as I've gone to pains to represent here, when it comes to functionality and prettiness, I error heavily on the side of functionality (where functionality includes safety and a premium on not making complex things harder to deal with than they need to be). My comments are really a tangent on the submission topic and not meant to be applied directly towards the specific solution Rust has gone with (there's a reason I waited until quite deep in the thread to use it specifically as an example). That is, .await is a perfectly acceptable outcome in my eyes without the need to justify it through syntax highlighting.

Aye, cheers. Understandable!

Given that my first syntax highlighting experience was Turbo Pascal 7.0 for MS-DOS, it always feels odd to see it disabled.

And we aren't in the late 70's anymore, where languages had design decisions (keywords always caps) due to printing limitations.

I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it. Traction control is a part of that landscape. Designing with awareness of syntax highlighting makes sense. But we should also keep an awareness that it won't always be there.

> I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it.

Yes, and if we outlawed the use of cars without traction control on certain roads, then I would be fine with designing with the assumption traction control will be on. But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers. I view that as different that just making the road safer for some.

> But we should also keep an awareness that it won't always be there.

Exactly. And this is why I think it doesn't make sense as a mitigation to a language level feature which will always be there.

Specifically, I think syntax highlighting is a useful feature and a plus for a comparison, I just don't think it works as a mitigation for a negative for something that pervasive.

All other things being equal, syntax highlighting abilities might push me towards one solution over another, but they won't make me ignore a problem I perceive with a solution.

I'm not sure if you read me as slightly more critical than I had intended or if I'm reading you as slightly more defensive than you'd intended, but I think we more-or-less agree: readability is important both with and without syntax highlighting, and tradeoffs should be considered in that light.

A nitpick:

> But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers.

Probably. But if a sufficient fraction of cars have traction control, and we sufficiently improve the performance of traction controlled tires at sufficiently small damage to the performance of other tires, the reduction in the threat of being hit by cars with traction control will outweigh the increase in risk of losing control for those cars without, even before trading off risk between cars (which is certainly more complicated).

I don't think there's a direct mapping back to syntax and highlighting.

> I'm not sure ... or if I'm reading you as slightly more defensive than you'd intended

That one. :)

> But if a sufficient fraction of cars have traction control, and we sufficiently improve the performance of traction controlled tires at sufficiently small damage to the performance of other tires

That's a slightly different scenario, where the change is to increase safety. Then it is, as you say, a trade-off. It could just as easily be a trade-off because material is cheaper though, in which case different calculations are important.

Also, it's important to be careful not to exclude important information from the calculation even if it's about a relative safety increase. For example, if you increase the safety for 90% of the people but decrease it for 10%, and that 10% is mostly comprised a population that is unable to switch and benefit (e.g. poor people with little choice in the vehicle they drive, as they drive what's available and cheap), you might not only be forcing that risk on an already captive population, but they might also be a population that is resistant to change that would mitigate this danger (they can't afford new cars and they can't afford better cars). Conversely, shifting risk to the wealthier (more elastic) part of the market might yield more of a net reduction in risk as they are capable and willing to respond to the increased risk (or more likely, increased annoyance).

> I don't think there's a direct mapping back to syntax and highlighting.

There isn't, we're getting into the weeds, but conceptually I think there are some interesting points that apply at least partially. For example, not all changes are felt and valued by the populations they affect similarly. E.g. not relying on syntax highlighting for a language feature does not affect a person that uses syntax highlighting that much one way or another (it will likely still be highlighted in some way), but it can impact those that don't or can't fairly heavily. If I'm stuck trying to review some bug while on vacation through some crappy online git interface that isn't highlighting code well, or maybe even at all, I'm going to curse the heavens if there's a feature that's easily missed or hard to follow in monochromatic output if it's causing me problems in my stressful moment.

Perhaps that's my sysadmin history coming through, but I want stuff to be simple, reproducible, and obvious. Complexity, fragility and obscurity are the enemy, and I fight them wherever I see them. ;)

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.

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

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.

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

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

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.

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.

It's not just learning the new notation. It's also that you probably can't override it with your own implementation (useful perhaps in embedded environments).

I don't see why you'd need to override await, because unlike in other languages Rust doesn't implicitly insert machinery for facilitating task execution. You need to provide your own task executor, which is the part that embedded environments would want to (and will be able to) have control over.