Disallow keywords as macro arguments names

[scottmcm]

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 Simple postfix macros rfcs#2442 and Introduce '$self' macro metavar for hygienic macro items rfcs#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.

[rustbot]

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]

Cross-referencing: rust-lang/reference#863

[joshtriplett]

I'll second this. I think it's a reasonable change to make, orthogonally to whatever further changes we might make that would use the syntax this reserves.

Clarifying edit: I'm agreeing in principle that this seems like a good idea and is worth pursuing, in the spirit of the MCP process, but I still expect that this will go through a crater run and similar to gauge impact.

[joshtriplett]

@rustbot second

[nikomatsakis]

Summary of Zulip comments:

• @kennytm notes that kennytm: "at least 131 uses of $self. this change would be too impactful to be done in one edition."https://sourcegraph.com/search?q=%5C%24%5BsS%5Delf%5Cb+repogroup:crates&patternType=regexp
• @jyn514 notes that they use $self quite often, in particular, and would have to change to $this

[nikomatsakis]

Discussion from 2020-11-10:

• Motivation: forwards compatibility with new ideas around macros
• Are self and super keywords in the sense we mean here? (We believe so, or at least they can't be used as variable names -- may be different from Self.)
• Would want to do a crater run to try and measure impact, but $self will be the most common
• Migration plan: $x can go to $r#x, for $self could do $this specifically (presuming it's not in use)
• Maybe we want to use a different syntax for things like $crate, that are not naming bindings but instead a "special path"

Conclusion of the meeting:

• Consensus that we need ability to expand macros in the future, but not convinced that $+keyword is the best plan, that would be one option but not the only one.
  • Have to decide who will lead that discussion if we feel it is in scope.
  • Note that alternative syntax would not require an edition change.
  • Crater run to evaluate impact.

[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.