Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macros can observe raw identifier state [discuss] #49520

Open
nikomatsakis opened this issue Mar 30, 2018 · 5 comments
Open

macros can observe raw identifier state [discuss] #49520

nikomatsakis opened this issue Mar 30, 2018 · 5 comments
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-epoch Working group: Epoch (2018) management

Comments

@nikomatsakis
Copy link
Contributor

In #48942, @Lymia landed raw identifiers; "equality" in this implementation includes observing the "raw" state. Therefore, macros can observe if r#foo was used or not:

#![feature(raw_identifiers)]

macro_rules! foo {
    (a) => {
        1
    };
    
    (r#a) => { 2 };
}

fn main() {
    println!("{}", foo!(a));
    println!("{}", foo!(r#a));
}

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 foo and r#foo.

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-epoch Working group: Epoch (2018) management labels Mar 30, 2018
@petrochenkov
Copy link
Contributor

petrochenkov commented Mar 30, 2018

Thanks for creating this issue, this is an interesting case.

@petrochenkov
Copy link
Contributor

petrochenkov commented Mar 30, 2018

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#a in 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.

@petrochenkov
Copy link
Contributor

petrochenkov commented Mar 30, 2018

One example:

macro my_macro {
    (struct { $i: ident }) => {}
    (construct { $i: ident }) => {}
}

From my_macro's point of view struct and construct are treated equivalently, regardless of their keyword status in Rust because it's irrelevant - my_macro just tries to match tokens provided in my_macro!(....) to tokens written in its LHS.
If this token matching ignores the rawness property, then my_macro should accept both r#struct { A } and r#construct { A }, if matching doesn't ignore the rawness property, then it should only accept struct { A } and construct { A }.

@nikomatsakis
Copy link
Contributor Author

@petrochenkov yeah, that makes a lot of sense, and I'm coming around to this POV

"Raw keywords" introduced by macros (r#a in 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.

@XAMPPRocky XAMPPRocky added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jun 29, 2018
@glmdgrielson
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-epoch Working group: Epoch (2018) management
Projects
None yet
Development

No branches or pull requests

4 participants