131–140 of 199 posts
Earlier quoted context omitted.
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 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;
Earlier quoted context omitted.
They worte explicitly that Rust went a different way than C#/JS
It's true, but that's around let result = do_stuff().await; vs let result = await do_stuff(); not what your parent is talking about.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 ne…
"{} + {}".format!("foo", "bar")
format!("{} + {}", "foo", "bar")
And postfix-macro syntax for await! would lead to code like
let result = sendRequest().await!()?.getBody().await!()?.Root;
let result = sendRequest().await!().try!().getBody().await!().try!().Root;
Earlier quoted context omitted.
Await is a keyword, syntax highlighters will most likely paint it differently.
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.
(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.)
Excited for the feature. 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...
`fut.await()` looks too magical. There's no hint in that expression that it's anything other than a method call. You could argue the same about `fut.await`, except in this case `await` is a keyword and thus the expression `x.await` is known to be an await expression without knowing anything about `x`, whereas `fut.await()` requires knowing the type of `fut` to understand that the method call `.await()` resolves to th…
Compared with `fut.await`...
> There's no hint in that expression that it's anything other than a field access.
At least there is precedence for functions to have magical compiler-ness for 'doing stuff', instead of overloading field access which is one of the simplest operations you can have.
> ... requires knowing the type of `fut` ...
tbh, you don't need to know how await works. It goes and does stuff and returns a value. If you need to know what it does, you're looking up the types and seeing, 'oh its a future' and looking at that.
Contrast with the field access one and you don't even know its something else entirely.
I guess I just don't buy that it can't be a method. Like, formally, yea, it isn't a well-defined, safe Rust method. But make the impl
fn await(self: Self) -> Self::Target {
intrinsic::await(self)
}
It's just frustrating, I guess.
Earlier quoted context omitted.
Yeah, this is really one of the only big warts, and hopefully not a trend. But the rest of the language is really good so don't let this scare you off. Most of rust feels very well thought out and reasonable.
OK, if the exceptions are quite exceptional and hoping, as you note, this doesn't represent a trend, I'll keep it in consideration. Thanks for the insight.
What a milestone! This was the most impressive work in open source decision-making that I have ever followed (in my limited experience). People have contributed thousands of comments discussing this for over a year. It has even caused the team to rethink how discussions like this should be guided in the future beyond comments on GitHub issues. I cannot imagine how difficult it has been to manage it all, and I applaud…
You'd be blown away by Linux Kernel development then. Multiple magnitudes above any measurement of an await syntax bikeshedding. /u/Perceptes puts it best than I ever could in this top voted comment on /r/rust [1]:
"...I personally don't care at all about the await syntax, and have been very unhappy with that bikeshed being such a focus of time and discussion. The real problems I have with the unstable async system are how difficult it is to reason about. Compiler errors are still largely indecipherable. impl Trait didn't really help here. Documentation is still sparse, so I spend a lot of time banging my head against the wall, trying many formulations of my programs to get just the right incantation of futures wrapped in futures wrapped in futures to get things to compile, only to get page-long type mismatch errors that are near impossible to read, and multiple closures/functions deep of nested futures being returned where any of them could be the culprit. I'm also very frustrated by the lack of progress on "abstract types" that are required for using async functions (and returning impl Trait) from trait methods. Traits are the cornerstone of Rust's type system and yet I haven't seen any activity on this for months. And now we're talking stabilization with this glaring hole. Async streams are another thing I've seen almost no progress on, aside from a blog post from withoutboats on how to deal with the ? operator within async for loops..."
This was 2 months ago, mind you. [1] https://www.reddit.com/r/rust/comments/awa3t1/baby_steps_blo...
I'm just glad that they finally settled on something.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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 ne…
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!().get…
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.