Hacker News Reader

Comment by jkarneges | Hacker News Reader

I figure the reason the proposed syntax looks gross is because other languages have been using a prefixed await for many years. The Rust decision seems well thought out though, enough to make me wonder if perhaps other languages have been doing it wrong.

My first experience with futures was in the form of QFuture (https://doc.qt.io/qt-5/qfuture.html), and there you call .result() to block and wait for the result. This postfixing is intuitive.

Rust's "?" operator is neat. I don't know if I've seen a postfix operator anywhere else yet. It's certainly possible Rust got this language aspect wrong, but as a user it feels pretty right.

Given the existence of the "?" operator, and the fact that futures resolution via postfix is intuitive (and not a new thing either), IMHO the best course of action probably is postfix. I'm not sure if literally ".await" is the best, but it's in the ballpark.

View on HN

IMO it's awkward for the following reasons:

(1) It looks like a field access, and field accesses are "cheap", method invocations aren't. This breaks the 'conceptual weight' model when you look at a line of code. Field accesses are simple and understood. It becomes impossible to gauge the 'cost' of a line by looking at it unless you're intimately familiar with the workings of 'await' and there's no visual cue.

(2) If we create new such postfix operators in the future we'll have to break yet more source code by reserving yet more field names in all structs in all existing code. This whole postfix thing is proving itself nice to work with so I'd prefer a path of less destruction if we do lean more into it.

(3) It's a one-off that's different from everything else in the language that's being shoehorned into existing syntax.

IMO, it's either break existing syntax by introducing something new or break semantics of existing syntax. I'll always lean towards the former over the latter. I like it being postfix, it's very much in the '?' family of ergonomics which has shown itself quite nice to work with. I'd prefer postfix "@await" or "!await".

> (2) If we create new such postfix operators in the future we'll have to break yet more source code by reserving yet more field names in all structs in all existing code.

This is already the case; all keywords in Rust are reserved keywords, not contextual keywords, so you already can't have a field named, say, `return`, despite the fact that a hypothetical `foo.return` would otherwise be unambiguous. Further, with the Edition system and rustfmt, reserving keywords in this manner shouldn't be disruptive.

> (3) It's a one-off that's different from everything else in the language that's being shoehorned into existing syntax.

The paragraph at the end of the OP suggests that the language team is seeking to propose allowing certain other keywords (specifically those that can return useful values) to be used in postfix position (which implies that `await` could then be used in prefix position as well), which could e.g. (I'm spitballing here) replace the `.for_each()` method on iterators with just `.for`.

> This is already the case; all keywords in Rust are reserved keywords, not contextual keywords, so you already can't have a field named, say, `return`, despite the fact that a hypothetical `foo.return` would otherwise be unambiguous. Further, with the Edition system and rustfmt, reserving keywords in this manner shouldn't be disruptive.

Well, the keyword could instead be "@await" instead of "await" meaning that no regressions would be introduced with field names, either now or in the future, right? Unless I'm mistaken, the '@' character isn't a valid prefix for an identifier.

> The paragraph at the end of the OP suggests that the language team is seeking to propose allowing certain other keywords (specifically those that can return useful values) to be used in postfix position (which implies that `await` could then be used in prefix position as well), which could e.g. (I'm spitballing here) replace the `.for_each()` method on iterators with just `.for`.

That's fine, I guess, but then we'd have yet more keywords we can't use. However, "@for" would not break anything. FWIW the way I read that section, the proposal enjoys little support.

Sure, the Rust developers could implement it such that `@await` worked, but `await` is already a reserved keyword as of the 2018 edition, so in this particular case it no longer makes any difference. For that matter, they could also have made it such that `.await` or `.anyotherkeyword` become legal in Rust 2015 (since keywords don't currently exist in that position, it wouldn't break any code). However this misses the point that the Rust developers have made a conscious philosophical decision to make their keywords reserved and not contextual. Reserving a keyword vs. contextualizing a keyword is a philosophical choice, not a technical one.

I'm not sure that the idea of contextual vs non-contextual keywords is relevant here unless I've misunderstood you. I assumed that the 'async' keyword was reserved in 2018 edition to ensure that no matter how they chose to implement it (prefix, postfix, whatever) they had the flexibility to pick after the fact. I don't think they closed the door on a new, non-breaking non-contextual operator, although I wasn't a party to any of those conversations.

Releasing 'async' and capturing '@async' would be 2015- and 2018- edition safe change unless there's something I've overlooked. It shouldn't break any 2018-edition code to make the 'async' keyword available, only to capture a new, currently-valid one, and I assume that's part of why they took this approach. I feel like the ball's still on the court until someone writes some valid 2018 edition code utilizing the keyword as defined in this proposal. This would also mark precedent for not reserving additional currently-valid keywords for postfix operations.

I'm proposing releasing 'async' and capturing '@async' as a new non-contexual composite keyword. In the state the language is right now, this change should keep the grammar context-free (except for raw string literals as is the case now afaik).

> there's no visual cue.

There is. Your editor is going to show the await keyword in a different color. (Unless you happen to be Rob Pike.)

There's nothing else in Rust that requires me to use an editor for a semantic cue, is there? Why start here? You are correct of course, it's more a question of Rust being just as useable right now with or without syntax coloring, this small change breaks a lot.

There's still a visual clue: You'll be in an async function, and it's highly likely that there'll be a question mark after it for control flow (e.g. most futures returns Result).

Postfix in itself is fine, although "await" as a verb reads best in a prefix position (cf. "try", "match", "yield", "loop", "return"). The reason the "dot await" notation looks gross is first and foremost because it coopts the field access syntax—familiar from almost every language in the C family—for a purpose entirely orthogonal to field access.

Good point. Maybe the best approach would be postfix but with a more fitting keyword than await. I wonder if alternative keywords were considered rather than only operators?

> it coopts the field access syntax [...] for a purpose entirely orthogonal to field access

You mean like C++'s a.this_method_is_a_function_call(...) did? Not to be confused with a.function_pointer_field(...), despite having literally identical syntax.

Personally, I think they should have intoduced a dot-keyword instead of postfix ?; it's too easy to miss, especially for something that hides a implicit return.

Meh, method calling is a fairly straightforward extension to field access, not something entirely different. Incidentally, in Rust you do have to disambiguate between calling a method and invoking a function through a function pointer field.

> I figure the reason the proposed syntax looks gross is because other languages have been using a prefixed await for many years. The Rust decision seems well thought out though, enough to make me wonder if perhaps other languages have been doing it wrong.

Lua[1], C++/Boost[2] also use "yield" it's not that uncommon and there is nothing new.

[1] https://www.lua.org/pil/9.1.html

[2] https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/ov...

It's not the question of keyword chosen, but rather where it should go.

I wrote a lot of async/await code in C#, where it's a prefix operator, and I think what they did makes more sense. C# syntax works great when all you're doing is awaiting on a single call per line, but as soon as you start doing e.g. method chaining, you have to put parentheses everywhere, and it gets real messy real fast. This looks cleaner.

At first I was firmly in the prefix camp, until I read one of the (massive!) GitHub issues on the subject and came around to postfix.

I'd _much_ rather use something like `?` than `.await`, though. Using a keyword just feels wrong in a few different ways.

Can you share said issue?

I don't know about GitHub, but https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1... summarizes the different tradeoffs pretty well.

Reply on news.ycombinator.com