Disallow keywords as macro arguments names

Proposal

Summary and problem statement

It was recently determined https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/postfix.20macros/near/216030097 that self and if and such are valid as identifiers in macros ($self, $if, etc).

That prevents adding new things like $crate, since there are no reserved identifiers. So it would be nice to treat them like normal identifiers, where keywords are not allowed. And because these are just identifiers, and thus unaffected by alpha-conversion, all expressible macros are still expressible. (And arguably not calling things $if is probably good.)

Motivation, use-cases, and solution sketches

• It’s more consistent to have the same identifier rules here as elsewhere
• Both https://github.com/rust-lang/rfcs/pull/2442 and https://github.com/rust-lang/rfcs/pull/2968 discussed adding $self with special meaning, which is currently a breaking change without this.

This would just be an edition change for the edition in which the macro is written.

Prioritization

This would need to happen fairly promptly if it were to make it for the 2021 edition.

Links and related work

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/postfix.20macros/near/216031552

Initial people involved

@joshtriplett

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[joshtriplett]

Discussion in today’s lang team meeting: the only urgency would be if we’re going to prohibit keywords, and that’s sufficiently high impact that we likely won’t end up doing it, even without having to do a full crater run. We’re more likely to accept an alternative syntax, such as $$ or similar, that isn’t currently valid syntax. And if we go that path, this doesn’t need to be tied to an edition.

[scottmcm]

The “let’s just do better in macros 2.0” from the meeting was persuasive to me.

Given that anything going to happen here would be substantially more than what I described in the OP, I’m going to close. Anyone motivated to take up the larger task should absolutely make a new proposal, however.