Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A final proposal for Rust await syntax

boats.gitlab.io

Post reply on HN
Print view View original

11–20 of 265 posts

Re: A final proposal for Rust await syntax

#11

Post by wyldfire »

ch wrote: post #2

Nice insight into the amount of thought going into this design proposal. It's always tricky to introduce new syntax to a language and re-using the field access notation here isn't as icky an approach as it first looks. I don't know enough about rust to understand how this would operate during compile time w.r.t if a user tries to define a field named 'async'. Is that no longer allowed or would the compiler be able to…

`await` was changed in rust 2018 to a keyword [1] and will now get a warning if misused IIUC. I'm guessing `async` keyword only shows up in contexts where identifiers aren't expected, so there's no ambiguity?

[1] https://github.com/rust-lang/rust/pull/54411

Re: A final proposal for Rust await syntax

#12

Post by lukeqsee »

james-mcelwain wrote: post #6

Really don't like the magic field access syntax.

> Really don't like the magic field access syntax.

From a language-feel and ergonomics standpoint, I agree. But the Rust team has made it pretty clear why a postfix is much more flexible, and I think we'll grow into it.

I do think it'll continue as a bit of a Rust oddity when compared to other async/await implementations (e.g., Python).

Re: A final proposal for Rust await syntax

#15

Post by drop_the_mike »

ch wrote: post #2

Nice insight into the amount of thought going into this design proposal. It's always tricky to introduce new syntax to a language and re-using the field access notation here isn't as icky an approach as it first looks. I don't know enough about rust to understand how this would operate during compile time w.r.t if a user tries to define a field named 'async'. Is that no longer allowed or would the compiler be able to…

If I'm not mistaken you couldn't have ever had 'await' as a field name because it's a reserved keyword. You can still use it by using the raw string syntax r# and that disambiguates when you access it to because it would be called like: expression.r#await

Re: A final proposal for Rust await syntax

#16

Post by cyphar »

Super excited to see async/await finally get close to MVP and landing. I am not a huge fan of ".await", but there isn't much more to be said -- my personal preference of "#await" or "@await" does look like line-noise and I think there's no perfect answer to this one (await{} was too messy and no better than prefix-await, and (await foo))? had too many brackets).

I also appreciate that this proposal was insanely bike-shedded and so really, any decision is better than no decision. I would've been happy with "await << f()" if it meant we could get this feature (lots of Rust projects I'm interested in are waiting on async/await before focusing on further development).

Re: A final proposal for Rust await syntax

#17

Post by cesarb »

To me, this syntax feels like a "magic" method call (like in languages where a field access can go through a getter method). That is, if you can think of "x.await()" as a compiler-implemented method call on x which does some stuff and returns a value (plus some magic to allow you to omit the parenthesis), this syntax looks intuitive enough.

Re: A final proposal for Rust await syntax

#18

Post by nchie »

Wow, this is the only suggestion I really didn't like. I'm really happy that it's progressing forward, but I can't help but feel that staying with the macro and postponing the decision would've been a better choice.

A language should, in my opinion, not depend on syntax highlighting.

Re: A final proposal for Rust await syntax

#19

Post by nixpulvis »

> Its very easy to build a mental model of the period operator as simply the introduction of all of these various postfix syntaxes: field accesses, methods, and certain keyword operators like the await operation. (In this model, even the ? operator can be thought of as a modification on the period construct.)

I like this explanation.

But this whole post could really use some more concrete examples of the at the very least the final style being used in various situations. Not just mainly `expression.await`.

Keep up the work on this, I'm excited to use this in my projects.

Re: A final proposal for Rust await syntax

#20

Post by Arnavion »

nchie wrote: post #18

Wow, this is the only suggestion I really didn't like. I'm really happy that it's progressing forward, but I can't help but feel that staying with the macro and postponing the decision would've been a better choice. A language should, in my opinion, not depend on syntax highlighting.

What good will postponing do? The blog post implies that it's already been debated for a long time and all the arguments seem to have already been brought forth. You can't just keep punting it forever; it has to get stabilized at some point.
Post reply on HN