4 ms·

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 tho

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

slezyr 7y ago
> 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 https://www.lua.org/pil/9.1.html [2] https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/overview/core/spawn.html https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/ov...
- int_19h 7y ago
  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.
M2Ys4U 7y ago
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.
- pablasso 7y ago
  Can you share said issue?
  - dbrgn 7y ago
    I don't know about GitHub, but https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1tPTCloXb2fmFpBTt~Ag-t9NlOSeI4RQ8AINsaSSyJ https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1... summarizes the different tradeoffs pretty well.
Sharlin 7y ago
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.
- jkarneges 7y ago
  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?
- a1369209993 7y ago
  > 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.
  - Sharlin 7y ago
    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.
arcticbull 7y ago
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".
- majewsky 7y ago
  > 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.)
  - swsieber 7y ago
    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).
  - arcticbull 7y ago
    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.
- kibwen 7y ago
  > (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`.

slezyr 7y ago

> 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 https://www.lua.org/pil/9.1.html [2] https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/overview/core/spawn.html https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/ov...

int_19h 7y ago
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.

M2Ys4U 7y ago

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.

pablasso 7y ago
Can you share said issue?
- dbrgn 7y ago
  I don't know about GitHub, but https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1tPTCloXb2fmFpBTt~Ag-t9NlOSeI4RQ8AINsaSSyJ https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1... summarizes the different tradeoffs pretty well.

Sharlin 7y ago

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.

jkarneges 7y ago
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?
a1369209993 7y ago
> 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.
- Sharlin 7y ago
  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.

arcticbull 7y ago

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

majewsky 7y ago
> 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.)
- swsieber 7y ago
  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).
- arcticbull 7y ago
  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.
kibwen 7y ago
> (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`.