Earlier quoted context omitted.
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.
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.
Update on await syntax in Rust
101–110 of 199 posts
Re: Update on await syntax in Rust
#102Earlier 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 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.
Re: Update on await syntax in Rust
#103Earlier quoted context omitted.
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.
`foo.await!()` would just expand to `(await foo())`, and anyone could write their own `my_await!` macro that works similarly.
Re: Update on await syntax in Rust
#104Earlier quoted context omitted.
I've been planning to try out Rust for a side project, and this decision is so principle-of-most-surprise that it's got me reconsidering, wondering what other unpleasant weirdness lurks in the language. Looking down their other options in one of the linked articles, they seem to reject a couple fine ones outright and then went with one I'd have rejected outright as being too hostile to anyone who's not quite familiar…
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.
Re: Update on await syntax in Rust
#105Earlier quoted context omitted.
> I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line. Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light. > Is this syntax for native coroutines? No. > Can it be combined with existing user and stdlib syntax? Yes. > What pathways for syntax developmen…
> Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light. Haven't we all found ourselves lined up as one of a pair of camps over some heated dispute over a bit of minutiae? The whole time you know it's a bit silly, but not entirely and you feel compelled to continue to argue. Using a term like "religious battles" with tongue firmly in cheek is reco…
Re: Update on await syntax in Rust
#106Earlier quoted context omitted.
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.
Re: Update on await syntax in Rust
#107Earlier quoted context omitted.
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;
var value = startRequest.await?.getBody().await?.Root;Re: Update on await syntax in Rust
#108Earlier quoted context omitted.
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.
instead of (await doSomething()).somethingElse()
doSomething()@await.somethingElse()
Re: Update on await syntax in Rust
#109Earlier quoted context omitted.
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.
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.
Re: Update on await syntax in Rust
#110Earlier quoted context omitted.
Postfixed and preceded by a dot is my understanding: pub async fn do_stuff() { // ... } // elsewhere, inside a fn // as svnpenn points out let result = do_stuff().await;
await goes inside the function, at least thats how its done with JavaScript - do you have evidence otherwise? https://developer.mozilla.org/Web/JavaScript/Reference/Opera...
chucksmash was concisely showing the syntax for an async function and how you can call it with await.