A final proposal for Rust await syntax
boats.gitlab.io
A final proposal for Rust await syntax
1–10 of 265 posts
Re: A final proposal for Rust await syntax
#2Nice 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 disambiguate?
Re: A final proposal for Rust await syntax
#3I'm anxiously awaiting this.
I just finished overhauling a rather involved Tokio/Future based project, and having await/async in the language spec will be a big step forward (and I'm hoping the compiler errors improve as well).
As always, kudos to the Rust team for making decisions that are well-reasoned and documented and in a way that looks to the future of the language (and not just meeting a feature deadline)!
Re: A final proposal for Rust await syntax
#4Nice 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…
> Is that no longer allowed or would the compiler be able to disambiguate?
I would speculate that both will be true. The compile could disambiguate, but it will not be allowed.
Re: A final proposal for Rust await syntax
#5Nice 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…
Disambiguation is easy when `await` is a keyword. [0] ;)
error[E0721]: `await` is a keyword in the 2018 edition
--> src/lib.rs:2:5
|
2 | await: i32
| ^^^^^ help: you can use a raw identifier to stay compatible: `r#await`
Re: A final proposal for Rust await syntax
#6Really don't like the magic field access syntax.
Re: A final proposal for Rust await syntax
#7Nice 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…
My guess is the raw identifiers syntax introduced in Rust 2018 (`r#` prefix) will handle this.
Re: A final proposal for Rust await syntax
#8Nice 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 you want to use async or await as a fieldname you have to write r#await and r#async because they are reserved in rust 2018.
Re: A final proposal for Rust await syntax
#9I'm anxiously awaiting this. I just finished overhauling a rather involved Tokio/Future based project, and having await/async in the language spec will be a big step forward (and I'm hoping the compiler errors improve as well). As always, kudos to the Rust team for making decisions that are well-reasoned and documented and in a way that looks to the future of the language (and not just meeting a feature deadline)!
If the way async/await has fundamentally changed how you write JavaScript code is any example, this will be a tectonic shift, especially for event-driven code like you use with Tokio.
Re: A final proposal for Rust await syntax
#10Nice 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…
afaik, as of Edition 2018, await is a keyword and one of the few(2?) reasons that the 2018 edition is not backwards-compatible with 2015.