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

RFC for allowing macros in all ident positions #215

Closed
wants to merge 1 commit into from

Conversation

Manishearth
Copy link
Member

  • Start Date: 2014-08-28
  • RFC PR: (leave this empty)
  • Rust Issue: (leave this empty)

Summary

Macros which resolve to idents should be usable in all positions that expect idents, including function/struct/enum names in definitions, et cetera.
Currently they can only be used as variable names.

Motivation

This will allow for creating better macros which resolve to functions. For example:

macro_rules! make_setter(
    ( $attr:ident ) => (
        fn concat_idents!(set_,$attr) (&self) -> u32 {
            self.$attr
        }
    );
)

can be created to generate setters just by calling make_setter(foo) (which will create set_foo())

Currently, using macros in this manner will lead to errors like

test.rs:1:17: 1:18 error: expected `(` but found `!`
test.rs:1 fn concat_idents!(Foo, Bar) () {
                          ^

See also: rust-lang/rust#13294

Detailed design

This will probably require converting ast::Ident to an enum allowing for a NamedIdent vs MacroIdent duality.

Drawbacks

None that I see

Alternatives

Suggestions welcome

Unresolved questions

I'm rather unsure about the implementation.

@SiegeLord
Copy link

I don't think blindly allowing macros everywhere is a good idea. For example, it might be cool to have syntax such as foo.bar!() which would pass foo to the macro bar! or something along those lines. This RFC, if implemented, would result in a much more useless interpretation.

@Manishearth
Copy link
Member Author

@SiegeLord This isn't about blindly allowing them everywhere; it's about allowing them where we alow idents. But yes, this would break that sort of syntax. I personally don't see many uses for that syntax though -- and besides we can always write bar!(foo) (whereas here the workarounds involve rather ugly and complicated syntax extensions)

@SiegeLord
Copy link

I don't mind making macro writer write ugly code in exchange for the macro user being able to write beautiful code. It is irrelevant that you can write bar!(foo), the whole point of that that syntax (and method syntax in general) is that you don't have to.

A use case for that syntax involves multi-dimensional slices for matrices (matrix.sl![0..5, 3..5]), keyword arguments (my_type.function!(arg1 = 1, arg2 = "abc")) and probably many other useful sugarings.

@Manishearth
Copy link
Member Author

The only workaround I know of is a syntext that's ugly to use

@brson
Copy link
Contributor

brson commented Sep 5, 2014

@Manishearth thank you for the RFC. Right now we are not adding major new features to macros for fear that Rust metaprogramming is becoming a huge, unspeccable mess. Closing.

@brson brson closed this Sep 5, 2014
@Manishearth Manishearth deleted the patch-1 branch February 1, 2015 08:33
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
Rewrite the stream::channel implementation
wycats pushed a commit to wycats/rust-rfcs that referenced this pull request Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants