A final proposal for Rust await syntax

Post by nixpulvis » Mon, May 06, 2019, 7:09 PM UTC

gamegoblin wrote: post #129

Sharlin wrote: post #35

Earlier quoted context omitted.

My dislike for the ”dot keyword” syntax has been strong, but if it is selected, hopefully it’s at least generalized to other keywords in the future, so that `.await` doesn’t stay a lone awkward exception to what dot notation means. In particular, I wouldn’t mind if in the future `expr?` could be spelled `expr.try` for consistency (even at the expense of introducing redundancy).

I wonder if I would ever find something like my_iter .foo() .bar() .return more appealing than return my_iter .foo() .bar(); I could see it happening, but I'll definitely need some time to get used to it.

Post by axaxs » Mon, May 06, 2019, 7:14 PM UTC

foota wrote: post #32

It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when conside…

Post by mintplant » Mon, May 06, 2019, 7:16 PM UTC

nixpulvis wrote: post #141

gamegoblin wrote: post #129

Earlier quoted context omitted.

I wonder if I would ever find something like my_iter .foo() .bar() .return more appealing than return my_iter .foo() .bar(); I could see it happening, but I'll definitely need some time to get used to it.

See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.

    let n = future_of_future_of_int
        .await
        .await;

Post by ajross » Mon, May 06, 2019, 7:27 PM UTC

pcwalton wrote: post #118

ajross wrote: post #103

Earlier quoted context omitted.

Not even if you paid me to have that fight, no. Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a…

> Why does a parametrized enumerant look like a function call and not a struct? Because tuples are considered good things to have in a modern language. Structs and enum variants are just named versions of tuples (denoted with parentheses) or records (denoted with braces—unnamed records don't exist in Rust). To follow languages like Python, they're written "(1, 2, 3)". (It would be weird if tuples were written "{1, 2,…

Post by pshc » Mon, May 06, 2019, 7:43 PM UTC

zzzcpan wrote: post #37

jerf wrote: post #25

"It has also devolved into a situation in which many commenters propose to reverse previous decisions about the design of async/await on which we have already established firm consensus, or otherwise introduced possibilities we have considered and ruled out of scope for now. This has been a major learning experience for us: one of the major goals of the “meta” working group will be to improve the way groups working o…

It's just means there is lack of trust to core designers. They haven't proven themselves to users, that they are capable of addressing their problems and align with their interests. Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. Not sure about Rust though.