Repository navigation
macros can observe raw identifier state [discuss] #49520
Description
Activity
- addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-epochWorking group: Epoch (2018) managementWorking group: Epoch (2018) management
on Mar 30, 2018 Thanks for creating this issue, this is an interesting case.
My reasoning (#48942 (comment)) when merging this behavior was that identifiers on the left side of a macro are keywords in the grammar introduced by that macro (each macro introduces a new grammar and doesn't care about keywords defined by the general language), so raw identifiers provide opt-out from those keywords in the same way like they provide opt-out for the large grammar of the whole Rust language.
"Raw keywords" introduced by macros (
r#ain the example above) are especially interesting - we don't have an analogue to them in the general Rust grammar. Maybe it makes sense to prohibit them on macros' left side, at least initially.One example:
macro my_macro { (struct { $i: ident }) => {} (construct { $i: ident }) => {} }
From
my_macro's point of viewstructandconstructare treated equivalently, regardless of their keyword status in Rust because it's irrelevant -my_macrojust tries to match tokens provided inmy_macro!(....)to tokens written in its LHS.
If this token matching ignores the rawness property, thenmy_macroshould accept bothr#struct { A }andr#construct { A }, if matching doesn't ignore the rawness property, then it should only acceptstruct { A }andconstruct { A }.@petrochenkov yeah, that makes a lot of sense, and I'm coming around to this POV
"Raw keywords" introduced by macros (
r#ain the example above) are especially interesting - we don't have an analogue to them in the general Rust grammar. Maybe it makes sense to prohibit them on macros' left side, at least initially.I agree with this. This would resolve a lot of my concerns, I think.
- addedA-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.
on Jun 29, 2018 Wait, it feels a lot more natural to simply not care. Like you said the grammar doesn't care about keywords or any other bit of syntax:
/// I should be able to do this because it's a macro macro_rules! blank { () => { ;} }
So this shouldn't make any difference.
- addedT-editionRelevant to the edition team.Relevant to the edition team.and removedWG-epochWorking group: Epoch (2018) managementWorking group: Epoch (2018) management
on Jul 24, 2025
In #48942, @Lymia landed raw identifiers; "equality" in this implementation includes observing the "raw" state. Therefore, macros can observe if
r#foowas used or not:This makes a certain measure of sense, but also makes me nervous, and I wanted to open an issue to discuss. For example, @Manishearth proposed making identifiers "raw" in macros when they are serialized, thus ensuring consistent interpretation as we cross editions.
I'm not entirely sure of the implications of this but it does make me nervous for users to be able to distinguish
fooandr#foo.