3 ms·

I'm not a Rust user, but I'm always keeping an eye on it as it drives for improved usability and intuitability. I really admire the open-mindedness and devotion

I'm not a Rust user, but I'm always keeping an eye on it as it drives for improved usability and intuitability. I really admire the open-mindedness and devotion toward improvement that the Rust community displays. One question I have about this update in particular: The raw identifiers syntax addition seems like syntax support for a convention. For example, I could use `r#for` or `_for` to solve the same problem, however, the first requires special syntax and the second doesn't. What does the syntax facilitate that a leading underscore doesn't?

shepmaster 8y ago
In edition 2018, Rust now has reserved `async` and `await` as keywords. Since crates written targeting edition 2018 need to interoperate with edition 2015 (and vice-versa), some syntax is needed to be able to use identifiers that are also keywords. For example, my 2015 crate might have a function `fn async(enabled: bool)` that I need to call from 2015. I could call it as `r#async(true)`. This follows the existing syntax of `r"foo"` / `r###"foo"###` for raw strings as well as raw byte literals: `br##"HELO"##`; Another use case will be for libraries like Diesel [0], a SQL query builder. People want to be able to search the documentation for SQL's `WHERE`, but `where` is keyword in Rust. They could choose to add a method called `r#where` to allow this kind of discoverability. [0]: https://diesel.rs/ https://diesel.rs/
- steveklabnik 8y ago
  I read the parent as suggesting that you could call it as _async(true)
  - shepmaster 8y ago
    Ah. If that's the case, as you point out people might have already been using a leading underscore (although they shouldn't for idiomatic reasons), leading to ambiguity around 2015 code: fn async(enabled: bool) {} fn _async(enabled: bool) {} 2018 code calling that: _async(true); // Which is this calling?
  - weberc2 8y ago
    No, this isn't what I meant to imply (though I understand your confusion). I didn't realize (or understand) that the syntax is meant to facilitate interoperability between different versions of Rust.
steveklabnik 8y ago
Well, making a leading underscore special would also be "syntax support", just in a different form. This particular idea was not brought up during the RFC process, though several alternative syntaxes were. Leading underscore is already a thing in Rust, see shepmaster's posts on why this is not enough. FWIW, we pretty much just followed existing languages here.
nickez 8y ago
r#for is really "for". The reason is backwards compatibility. Rust 2018 may have new keywords which can be used for symbol names in 2015 crates. So to be able to reference such symbols from a 2015 crate in a 2018 crate you need this new syntax.
mark-simulacrum 8y ago
The future use for this will be to allow calling methods/functions/macros from 2015 edition code in 2018, where some additional keywords have been reserved. For example if you are using a crate with "dyn" as a method name then from 2015 you can call it via some_crate::dyn() but in 2018 you couldn't, since it's a keyword, but you could use some_crate::r#dyn(). That's the primary intent for this addition, though I believe some other use cases might be available as well.

shepmaster 8y ago

In edition 2018, Rust now has reserved `async` and `await` as keywords. Since crates written targeting edition 2018 need to interoperate with edition 2015 (and vice-versa), some syntax is needed to be able to use identifiers that are also keywords. For example, my 2015 crate might have a function `fn async(enabled: bool)` that I need to call from 2015. I could call it as `r#async(true)`. This follows the existing syntax of `r"foo"` / `r###"foo"###` for raw strings as well as raw byte literals: `br##"HELO"##`; Another use case will be for libraries like Diesel [0], a SQL query builder. People want to be able to search the documentation for SQL's `WHERE`, but `where` is keyword in Rust. They could choose to add a method called `r#where` to allow this kind of discoverability. [0]: https://diesel.rs/ https://diesel.rs/

steveklabnik 8y ago
I read the parent as suggesting that you could call it as _async(true)
- shepmaster 8y ago
  Ah. If that's the case, as you point out people might have already been using a leading underscore (although they shouldn't for idiomatic reasons), leading to ambiguity around 2015 code: fn async(enabled: bool) {} fn _async(enabled: bool) {} 2018 code calling that: _async(true); // Which is this calling?
- weberc2 8y ago
  No, this isn't what I meant to imply (though I understand your confusion). I didn't realize (or understand) that the syntax is meant to facilitate interoperability between different versions of Rust.

steveklabnik 8y ago

Well, making a leading underscore special would also be "syntax support", just in a different form. This particular idea was not brought up during the RFC process, though several alternative syntaxes were. Leading underscore is already a thing in Rust, see shepmaster's posts on why this is not enough. FWIW, we pretty much just followed existing languages here.

nickez 8y ago

r#for is really "for". The reason is backwards compatibility. Rust 2018 may have new keywords which can be used for symbol names in 2015 crates. So to be able to reference such symbols from a 2015 crate in a 2018 crate you need this new syntax.

mark-simulacrum 8y ago

The future use for this will be to allow calling methods/functions/macros from 2015 edition code in 2018, where some additional keywords have been reserved. For example if you are using a crate with "dyn" as a method name then from 2015 you can call it via some_crate::dyn() but in 2018 you couldn't, since it's a keyword, but you could use some_crate::r#dyn(). That's the primary intent for this addition, though I believe some other use cases might be available as well.