Live data from Hacker News

Update on await syntax in Rust

boats.gitlab.io

101–110 of 199 posts

Re: Update on await syntax in Rust

#101
post #71

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.

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

#102

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

#103

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

Would the macro case be addressed by also supporting a prefix keyword? The post that states macros can't work does not cover this. From what I can tell:

`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

#104
post #85

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

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.

Re: Update on await syntax in Rust

#105
post #59

Earlier 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…

This gets trickier when you have a community where some people practice religion in their daily life, and some people don't, and where the interactions between the two aren't always fun. It's not that the subject needs to be totally forbidden of course, but when it's just as easy to use different metaphors, we might as well.

Re: Update on await syntax in Rust

#106

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

It's a better case for showing how to use .map().

Re: Update on await syntax in Rust

#107
post #82
post #71

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.

For ease of comparison, here's how that would look with syntax akin to Rust's choice: var value = startRequest().await.getBody().await.Root;

Assuming these are failable actions then this would probably end up looking like

  var value = startRequest.await?.getBody().await?.Root;

Re: Update on await syntax in Rust

#108

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

It seems there's a conflict between the logical flow of prefixes going right to left and postfixes going left to right. I wonder if there's any value (for other future languages) in having syntax to swap post and prefix for convenience

instead of (await doSomething()).somethingElse()

doSomething()@await.somethingElse()

Re: Update on await syntax in Rust

#109

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

Yeah, I think the trick is that the theory and practice might be the same. And usually, it's the other way around; spreading it out makes it work, whereas it may not otherwise. For example:

    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

#110
post #45

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

I think it should be fairly clear that it's inside an async function, I mostly don't think that was part of the question, which was about syntax.

chucksmash was concisely showing the syntax for an async function and how you can call it with await.

Post reply on HN