Support matching interpolated types in macro invocation syntax

[zargony]

It would be nice if macros could be invoked using an interpolated type from a transcription of another macro.

This is my macro to convert C typed values from an external library to Rust types:

macro_rules! c_to_rust(
  ($v:ident c_int) => ($v);
  ($v:ident *c_char) => (str::raw::from_c_str($v));
)

It works fine when invoked like c_to_rust!(i: c_int), but it can't be used from within another macro using an interpolated type like c_to_rust!($v: $ty) (where the macro's invocation contains $v:ident, $ty:ty) - probably because interpolated types cannot be matched literally in the invocation syntax.

Here's my other macro which fails to use the above one. For bindings to an external library, I need to provide a lot of callback functions. So I'm using a macro to define them, since they only differ in name and parameter types. But I want the forwarding function to convert the parameter to Rust types before passing them along, which unfortunately doesn't work. (Any hints on how to work around this are welcome, I didn't find a suitable way without repeating a lot of code)

macro_rules! forward_callback(
  ($fn_name:ident, $op_name:ident, $($param_name:ident: $param_type:ty),*) => (
    extern fn $fn_name (userdata: *c_void, $($param_name: $param_type),*) {
      unsafe {
        let session: &Session = cast::transmute(userdata);
        session.$op_name($(c_to_rust!($param_name: $param_type)),*);
                                                    ^~~~~~~~~ FAILS
      }
    }
  );
)

// Intended use:
forward_callback!(function1, p1: c_int)
forward_callback!(function2, p1: c_int, p2: *c_char)

[Aatch]

Hmm, I'm not sure if this is actually a error. Rust macros work on token-trees, not text. Since c_int is just a literal token for the string c_int, it won't match against a type token, which is what your forward_callback! produces.

As for a workaround, you could add another clause to c_to_rust! that matches any type.

The only thing I could see is maybe adding a bit of logic to allow specialisation on tokens. So you could say, "match a type token that is c_int".

[zargony]

Yes, this is more like a feature request than a bug report :). In my case, it would have been nice to be able to match on types. I guess I tried to add some kind of polymorphism to the c_to_rust! macro with it (which I'd find useful to be supported)

Adding a clause that matches any type wouldn't help since I needed different types to be handled differently. The only way I found to work around it is to define a trait ToRust and implement a to_rust function for every desired type - which ended way more lengthy than I thought it would be.

[pnkfelix]

@Aatch you raise an interesting point there: it seems like this is a place where the macro system is falling down.

In your suggestion to add logic for specialization on tokens, was there any particular syntax you were thinking of? Off the top of my head, I was thinking perhaps something like:

macro_rules! c_to_rust(
  ($v:ident c_int:ty) => ($v);
  ($v:ident $(*c_char):ty) => (str::raw::from_c_str($v));
)

where the trailing : $ty is meant to be analogous to how the pattern bindings are assigned types, but now instead of having a pattern binding before the colon, it is instead a type expression that must be matched. Though it seems like this particular idea might be fraught with usability perils, in terms of how far the ":ty" might occur from the beginning of the left-hand-side...

Another idea for a syntax is:

macro_rules! c_to_rust(
  ($v:ident $t:ty) if $t match c_int => ($v);
  ($v:ident $t:ty) if $t match *c_char => (str::raw::from_c_str($v));
)

which might be an easier syntax to both use and also implement.

[catamorphism]

(bug triage) No updates here.

[steveklabnik]

Triage: macro stuff has been stabilized, anything more would need an RFC. If this is worth porting over to an RFC repo issue, please let me know.