Reserve macro identifiers

[Manishearth]

Rendered view

[eddyb]

Something that has been on my mind is using \ for escaping: we already need something like $($foo:ident)\+* to work, and this would also allow some future multi-level $ escaping, in a consistent manner.

[Manishearth]

@eddyb That seems like a good idea-- however backslashes in macro definitions don't work anyway, so there's no need to reserve anything for now.

[huonw]

I don't think $$foo can currently be used for any syntax variables inside a macro_rules! (although it is definitely a valid sequence of tokens to pass to macros), and $_foo is just a syntax variable called _foo, which, to me, feels like a valid way to indicate that something is not being used (and I personally use it this way).

[Manishearth]

@huonw Yeah, I noted in the RfC that it can't, but since it's a valid token to pass to macros I probably should edit the RfC to ask for it to be reserved everywhere.

As for $_foo, whenever a discussion crops up when we need a special builtin identifier for something in the context of macros, somehow the dollar-underscore combination always comes up. Since macros don't lint unused variables anyway, I guess it's not much of a disadvantage if $_foo is reserved.

[huonw]

whenever a discussion crops up when we need a special builtin identifier for something in the context of macros

FWIW, I've never seen any discussion of this form. I actually find it incredibly ugly (mainly theoretically, but also syntactically) but maybe because I'm just reading it as a token sequence $, _foo rather than the psuedo-token sequence $_, foo.

Since macros don't lint unused variables anyway, I guess it's not much of a disadvantage if $_foo is reserved.

Yet: there has been a few times where a bug in one of my macros would have been solved by being told that something was unused. I do see removing the option to add these diagnostics as a disadvantage.

[Manishearth]

@huonw Hm, agreed. So what about simply focusing on $$foo and reserving tokens of that form? Or picking another prefix to reserve (I'd rather have both $$ and something else)?

[lifthrasiir]

How about reserving $UPPERCASED variables instead?

[Manishearth]

@lifthrasiir That's an interesting idea, but that seems to be too restrictive. Especially since it would leave out one-letter ones which might be useful.

[reem]

I prefer reserving $$foo for compiler-blessed stuff myself, I find it much more pleasing to look at then $_, which makes me think it is supposed to be hidden.

[Manishearth]

@reem What if we need more than one? In the case of higher order macros, we might need a distinction. (eg $$ for user-defined higher order thingies, something else for compiler-blessed magic words)

[paulstansifer]

I believe that we're planning on using $$ to escape $ for macro-defining macros, though.

Another factor: we will eventually need to have special syntax for identifier concatenation: perhaps the two special syntaxes for these things could be related.

[Manishearth]

Oh, right. In that case $$foo is out of the question. Anyone have any other ideas for a prefix?

[reem]

Why don't we use \$foo to escape macros-producing-macros? That feels more natural to me than $$ for escaping.

[huonw]

(Background: the macro-producing-macro syntax is covered by rust-lang/rust#6994.)

[nikomatsakis]

During triage meeting, we discussed this PR and decided to close it. We already know we will eventually require a mechanism for introducing keywords into the language as a whole, and that same mechanism could presumably be used here as well. Furthermore, $$ is already reserved, as the RFC notes, which seems adequate.