5 ms·

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

by ch 7y ago

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?

lukeqsee 7y ago
> 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.
jmcomets 7y ago
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&edition=2018&gist=b3999aad31966f91af75d501358d02bd https://play.rust-lang.org/?version=stable&mode=debug&editio...
- msla 7y ago
  Programming languages didn't used to have reserved words: https://en.wikipedia.org/wiki/Reserved_word 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 7y ago
    >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 7y ago
    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 7y ago
      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 7y ago
        XQuery is probably a more recent example of that. No reserved words there, just syntax. https://www.w3.org/TR/xquery-30/#nt-bnf https://www.w3.org/TR/xquery-30/#nt-bnf
moosingin3space 7y ago
My guess is the raw identifiers syntax introduced in Rust 2018 (`r#` prefix) will handle this.
erk__ 7y ago
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.
mqus 7y ago
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.
wyldfire 7y ago
`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 https://github.com/rust-lang/rust/pull/54411
drop_the_mike 7y ago
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

by ch 7y ago

lukeqsee 7y ago

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

jmcomets 7y ago

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&edition=2018&gist=b3999aad31966f91af75d501358d02bd https://play.rust-lang.org/?version=stable&mode=debug&editio...

msla 7y ago
Programming languages didn't used to have reserved words: https://en.wikipedia.org/wiki/Reserved_word 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 7y ago
  >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 7y ago
  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 7y ago
    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 7y ago
      XQuery is probably a more recent example of that. No reserved words there, just syntax. https://www.w3.org/TR/xquery-30/#nt-bnf https://www.w3.org/TR/xquery-30/#nt-bnf

moosingin3space 7y ago

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

erk__ 7y ago

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.

mqus 7y ago

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.

wyldfire 7y ago

`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 https://github.com/rust-lang/rust/pull/54411

drop_the_mike 7y ago

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