81–90 of 199 posts
Disappointed we didn't get something like a magic method (e.g., lang item) (which isn't without precedence [1] [2]) so we could have had `Future::await(fut)` or `fut.await()`.
[1] - https://manishearth.github.io/blog/2017/01/10/rust-tidbits-b... [2] - https://manishearth.github.io/blog/2017/01/11/rust-tidbits-w...
Earlier quoted context omitted.
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,…
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.
var value = startRequest().await.getBody().await.Root;Earlier quoted context omitted.
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.
I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...
EDIT: nvm. it says in TFA not the linked writeup
I'm not familiar with Rust, someone can explains why they went with .await? Is await a field / method on a class / struct?
None of the above. It's compiler magic. It's a keyword that says 'await on this awaitable object' (currently only a Future can be await-ed). You can read the OP which contains links to more blog posts on the reasoning. I think this is a bad decision precisely because of the questions you're asking. At least making it a 'magic method' (i.e., Future::await(...) or future.await()) with no implementation would have been…
I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...
(It's certainly desirable for performance and compatibility to avoid making all subroutines into coroutines, so I understand why most languages have done this.)
And restricting it to the case where coroutines have a single return...
Subroutines are naturally coroutines that don't yield. And it seems like the question of whether it's a subroutine or a coroutine shouldn't be something the programmer needs to worry about.
What I've seen in coroutine libraries is the main reason we need await seems to be for cases when we don't want to await a result.
If you need an unawaited invocation to pass to a routine like gather, you do this:
my_results = await gather(run_job(x) for x in work)
my_results = gather(run_job.future(x) for x in work)
alpha = run_alpha()
beta = run_beta()
gamma = run_gamma()
return alpha + beta + gamma
alpha = run_alpha.await()
beta = run_beta.await()
gamma = run_gamma.await()
return alpha + beta + gamma
I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...
Earlier quoted context omitted.
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,…
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.
var temp1 = await StartRequest();
var temp2 = await temp1.GetBody();
var value = temp2.Root;