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.

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/

I read the parent as suggesting that you could call it as

  _async(true)

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.

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?

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.

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.