[ch]

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

[jmcomets]

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`

[0] https://play.rust-lang.org/?version=stable&mode=debug&editio...

[msla]

Programming languages didn't used to have reserved words:

https://en.wikipedia.org/wiki/Reserved_word

> Not all languages have the same numbers of reserved words. For example, Java (and other C derivatives) has a rather sparse complement of reserved words—approximately 50 – whereas COBOL has approximately 400. At the other end of the spectrum, pure Prolog and PL/I have none at all.

I don't really know why modern programming languages bother with reserved words. Yes, it would be confusing to have a variable named 'if', but compared to all of the other ways to write confusing code in, say, C, that's barely a drop in the bucket. Plus, it's something good tooling (highlighting, for example) could obviate, as it's entirely possible to use a grammar to show exactly what role each token is playing in a statement.

[Nadya]

>I don't really know why modern programming languages bother with reserved words

Preventing potential footguns prevents a large number of bugs. In fact, preventing a specific kind of footgun is one of the primary reasons that Rust exists.

Fewer footguns means easier to work with code. Easy to work with code means fewer bugs. If having reserved words removes more footguns than it creates than they are a good thing to have - and IMO - they do indeed prevent confusion and footguns.

As long as these footguns can be removed without giving up much in exchange, I say remove all footguns!

[sinistersnare]

I don't know about PL/I but Prolog kind of cheats, in my opinion, about the reserved words. It is very strict about naming conventions, which is (IMO) worse than having reserved words.

[msla]

PL/I is syntactically like Algol, or Pascal, or C with more words and fewer brackets. At heart, it's a "normal" block-structured procedural programming language, which proves that a C clone could adopt the same basic idea.

[int_19h]

XQuery is probably a more recent example of that. No reserved words there, just syntax.

https://www.w3.org/TR/xquery-30/#nt-bnf

[wyldfire]

`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

[erk__]

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.

[lukeqsee]

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

[moosingin3space]

My guess is the raw identifiers syntax introduced in Rust 2018 (`r#` prefix) will handle this.

[mqus]

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.

[drop_the_mike]

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