Allow item macros to take type parameters

[eholk]

It might be able to write item macros that have type parameters associated with their identifier, such as:

generate_something! foo<T, U> { }

Especially in cases where we are making macros that expand into functions, enums, types, etc., it might be nice to have a single set of type parameters for all of the generated code.

This issue is relevant to #3165.

[graydon]

retagged as enhancement; can you give some background on how you'd expect this to work? How would the type terms be bound in the macro environment?

[eholk]

Maybe we could do something like have macro patterns specify the whole pattern, instead of just the arguments. For example, you might write:

macro_rules! {
    generate_something! $name:ident<$T:type, $U:type> { ... } => ...
}

Then the name and type variables would be bound just like any other macro pattern variable.

[emberian]

/cc @paulstansifer @jbclements

[paulstansifer]

Just to clarify; this is an aesthetic request, right? The parameters would behave the same way as $t1:ty parameters given inside the parentheses of the macro invocation?

[eholk]

That seems right to me. It's just to make the macro invocations look more like other items that can have type parameters.

[jbclements]

I oppose this on syntactic purity/simplicity grounds, unless we could find some super-nifty way to define rust's set of supported syntactic forms in such a way that the macro code and the non-macro code were actually using the same parsing code, a la Honu. Just my opinion, of course.

[huonw]

Triage: no change; #10413 would make this less important (although rather ugly, with the type parameters inside the {}).

[kmcallister]

Closing this as wishlist / RFC. It's something to consider alongside the "item macro sugar" that was proposed (and rejected) for RFC 453.