Pre-RFC: Raw identifiers

Seeing the choices in actual code I think I prefer the look of \catch, all else being equal.

Backslash and at-sign do have the downside of not being delimited syntaxes so you need some rules to detect the end of the identifier, I assume if we go for a syntax like that then we’d limit it to being like a normal identifier, which would make this only useful for escaping keywords and not much else.

Potentially it could be extended a bit... but allowing a character like `:` in an escaped identifier would be really annoying for code like `foo::\catch ::Bar { \catch : 5 }` requiring forced whitespace (assuming whitespace is not allowed, but some people probably do want whitespace in their identifiers).

As @matklad mentioned using a delimited syntax like `catch` allows for easily extending the characters allowed in the identifier, which may be useful for things like FFI to languages that have a wider valid identifier character set. It does make it a more heavy-weight syntax, I don’t think I would use `struct` instead of strukt in proc-macros, whereas I have used @class heavily in reflective C# code.

I think deciding whether these raw identifiers should support just reserved, normal-syntax identifiers; slightly extended syntax identifiers; or full, anything goes, string-like identifiers; would be a good first bikeshed before really arguing over the exact characters used to represent the rawness of the identifiers.


If we go with string-like identifiers in backticks, do we also need a raw form of that?

enum Foo {
    `that was a keyword!`,
    `we can escape like \`catch\` too`,
    `but if we want a \\ in our identifer`,
    r`maybe we'll want raw \ like this`,
    r#`and use raw ticks `\` like this`#,
    r##`even `\` and `#` together`##,

It’s a deep rabbit hole!

But it could also be progressively expanded. Start with just identifier characters to address reserved keywords, then open it up to any characters with \ escaping, and then maybe go all the way to really raw forms.


Yes, I think you’re right. The only use would be as a shorthand if you want to avoid some kind of mangling attribute on every foreign declaration.

I personally don’t much like \catch since \ is almost universally a single-character escape elsewhere rather than a whole-word escape, so it looks odd to me (though I’m sure I would get used to it over time).

I’ll just throw \{catch} into the pot as an idea while I’m here.

This looks great!

Personally, I was happy when I saw the r#catch syntax. It’s reasonably short, fits decently with other syntax, and doesn’t take up a new sigil that I’d rather keep for a more important use.

I think that having a short syntax is far more important in C# because of reflection and anonymous struct literals. Razor uses things like new { @class = "errorbox" } all over the place as an inefficient associative container, with the field names appearing in the output. I hope Rust doesn’t develop such a pattern.

A possible extension: this could allow both identifier#catch and keyword#catch (probably with shorter prefixes) as a way to also expose catch in Rust 1.0 (or multi-version) code.

Anything except r#… and br#… will break Macros 1.0.

macro_rules! x {
    ($a:ident # $b:ident) => {};
    ($c:ident) => { should error };

Hmm, that macro example also rules out @catch, but \catch and `catch` should still be OK because those characters aren’t yet found in legal tokens. (error: unknown start of token: \)

1 Like

Many C dialects support $ as a character in identifiers (probably for compatibility with VMS), so this might help with FFI if someone uses this particular C feature.

So any new literal kind? That’s a shame, and blocks things like s"foo" for Strings too, I guess.

I often feel like every possible syntax addition is breaking for macros…

If possible, I’d like to keep ` unused so writing docs and posts here stays easy :smile:

#[derive(Copy, Clone)]
struct s;

impl std::ops::Div<&'static str> for s {
    type Output = String;
    fn div(self, literal: &'static str) -> String {

fn main() {
    let _strings: &[String] = &[s/"hello", s/"we", s/"are", s/"strings", s/"😛"];

But seriously, the syntax "foo"s (a suffix s) is reserved and can be used for this.


True, but you can also rename it locally, like #[link_name = "foo$bar"] fn foo_bar().

Having struggled with it here a few times, I’m with you on that. :slight_smile:

Lisp and Ruby use a leading colon for symbols (e.g. :catch), so maybe that would help make it easier to learn for people who have seen that pattern before?

Stealing @cuviper’s example:

use foo:::catch::bar;
let foo = :catch { bar: 42 };
let foo = Foo { :catch: 42 };
foo.:catch = 42;

Personally I think the `catch` variant isn’t as visually distracting as @catch or r#catch. Although using a delimited string for idents means a function name can now contain spaces, which looks odd after all these years of only allowing alphanumeric and underscores in an identifier.

Lisp uses them for keyword symbols, which are symbols in a special namespace. Symbol quoting uses |…| quoting.

1 Like

Question: how important is the catch problem in practice? How many crates out there indeed use catch as a name of a field or method?

Unknown – maybe not at all. I think the only reason catch couldn’t be a contextual keyword was for the possibility of a struct catch (which already defies naming conventions) and thus catch { ... } constructing it. But that was enough of a blocker that we now have do catch { ... } for the expression, and the keyword breaking change was discussed in the epoch proposal.

I’ve been reminded (by renewed activity) that there is a competing proposal, Infix notation for function call / invocation, that wants to use \foo for something else.

Thanks, then we can also look at raw identifiers used as such infix operators:

  • a \r#catch b
  • a \`catch` b

(in the realm of “silly but syntactically allowable”)

Among 10165 crates from, 28 use catch identifier for some definition. At least some of them use catch in public API. Full report is here:


As a data point, Dart uses #ident - it also has it for operators, so #+ refers to the method defined as operator+ (borrowed from C++), equivalent to our Add::add.

1 Like

We need to do something like this to ever be able to create new reserved words (necessary for the catch syntax for example). I think @cuviper’s proposed syntax strikes a good balance between sugar and salt, and the point about r# or br# being the only syntaxes that don’t break 1.0 macros seems compelling also.

I’d encourage someone to post an RFC.

1 Like