Macros should be able to expand to methods

[catamorphism]

Requested in a FIXME (formerly XXX) in rustc::middle::lang_items

More specifically, here is (an abstraction of) the code pattern that the FIXME is noting:

pub enum E { Enil, Ergt, Elft, Eall, /* ... */ Eend, }
pub struct S { items: [int, ..5] }

pub impl S {
    pub fn name(index:uint) -> &'static str {
        match index {
            0 => "nil", 1 => "lft", 2 => "rgt", 3 => "all",
            4 => "end", _ => "???"
        }
    }

    // The cases below are where a macro that expands into a method
    // definition is of interest, since they are all very regular.
    pub fn nil_item(&self) -> int { self.items[Enil as uint] }

    pub fn lft_item(&self) -> int { self.items[Elft as uint] }

    pub fn rgt_item(&self) -> int { self.items[Ergt as uint] }

    pub fn all_item(&self) -> int { self.items[Eall as uint] }

    pub fn end_item(&self) -> int { self.items[Eend as uint] }
}

    // Presumably the macro invocation version would look something like:
    //   macro_rules! e_method( 
    //      $method $variant
    //      =>
    //      pub fn $method(&self) -> int { self.items[$variant as uint] }
    //    )
    //
    // pub impl S {
    //   pub fn name(index:uint) -> &'static str { ... }
    //   e_method!(nil_item Enil);
    //   e_method!(lft_item Elft);
    //   e_method!(rgt_item Ergt);
    //   e_method!(all_item Eall);
    //   e_method!(end_item Eend);
    // }


fn main() {
    let s = S{ items: [0, 2, 1, 3, 4]};
    io::println(fmt!("Hello World: %?", s.all_item()));
}

[pnkfelix]

�While I could not find a way to directly express the desired form, there is a way to get some abstraction here: Namely, instead of trying only to make a macro that expand into a method definition (which do not currently appear in a macro-expansion context, the first of a number of obstacles in the way of resolving the above), one can make a macro that expands into the whole impl itself.

My first attempt to do this tried to factor the impl into its non-repetitive (e.g. the name method in the example I added to the issue description) and repetitive components, and then feed both of those sequences of pseudo-items into a single macro that would expand into the final impl. However, this attempt failed, since I was not able to coerce the expander into accepting my factored name method definition as a proper component to be spliced into the final impl item.

So I gave up on that more general factoring, and instead came up with the below, which does seem to work. Its pattern might be applicable to the repetitive code from rustc::middle::lang_items, at the cost of making it a little bit more obtuse for a casual reader. (But anyone who is used to seeing similar abstractions in C macros probably will not mind it.) Here is the code:

macro_rules! e_class(
    ($S_name:ident,
     $( $method_name:ident $enum_name:ident ),*)
    =>
    {
        pub impl $S_name {
            pub fn name(index:uint) -> &'static str {
                match index {
                    0 => "nil", 1 => "lft", 2 => "rgt", 3 => "all",
                    4 => "end", _ => "???"
                }
            }

            $( pub fn $method_name (&self) -> int { self.items[$enum_name as uint] } )*
        }
    }
)

e_class!( S,
          nil_item Enil ,
          rgt_item Ergt ,
          lft_item Elft ,
          all_item Eall ,
          end_item Eend )

[pnkfelix]

@PaulS @catamorphism There are a couple different issues that crop up here. E.g., I had some difficulty feeding in a method definition to be plugged in from the outside world; that might just be my own inexperience, I don't know.

But the more important overall question raised by this Issue is: Do we want the method definition points within impl's to be subject to macro expansion? I suspect we do (and thus am not closing this bug yet); but if we don't, then I assume something like the workaround I outlined in my previous comment would be suitable here, and we could close this bug (or whittle it down to the other narrower issues I alluded to already).

[pnkfelix]

Nominating for milestone Far Future.

[graydon]

accepted

[catamorphism]

(bug triage) Revisited. Far-future still seems reasonable.

[huonw]

Traige: no changes, although I've written a brief proposal at #7727 (comment) about how we could make macros more flexible.

[chris-morgan]

With #10832, this is not as important as it was previously, as the lang_items.rs use case is no longer of interest.

[pnkfelix]

#10832 is basically adopting the work-around I proposed in my comment above.

So I'm in favor of closing this unless people can find arguments for making method definition points within impl's to be subject to macro expansion. (I'm ambivalent on the matter.)

[Skrylar]

I just ran in to this and there is at least one good use case: Library binding.

For example in SDL there are a lot of times where you simply want to bind Window.DoSomething to SDL_DoSomething(self.handle), and a macro allows you to define that function form once. Further methods which have the same common signature can just invoke the macro, which cuts down the amount of typing as well as functions with completely identical structures.

Maintaining by hand, you get a lot of functions like this:

impl Window {
  pub fn DoSomething(&self) {
    unsafe { ffi::SDL_DoSomething(self.handle); }
  }
}

Which is exactly the kind of thing you want a macro producing a function for: replacing large amounts of boilerplate which has the same structure in each invocation.

[sfackler]

@Skrylar is there any reason that you can't structure the macro to generate the entire impl block? That works fine right now.

[Skrylar]

@sfackler It just seems more idiomatic after reading the manual to be able to macro out the common case directly where you need it, instead of flipping around the entire block as a macro chalk full of "special case" conditions for that macro which simply insert raw functions in. Since you inevitably have that one function in every library that takes in a weird number of oddly typed parameters, you still have to key in functions that there's only one of with that type signature.

[sfackler]

I'm still not sure what you're saying. What exactly is wrong with a setup like this?

macro_rules! build_window_ffi(
    ($name:ident, $raw:ident, $ret:ty, $($arg_name:ident: $arg_ty:ty => $raw_arg:expr),*) => (
        impl Window {
            pub fn $name(&self, $($arg_name: $arg_ty),+) -> $ret {
               unsafe { ffi::$raw(self.handle, $($raw_arg),+) }
            }
        }
    )
)

build_window_ffi(DoSomething, SDL_DoSomething, ())
build_window_ffi(DoSomethingElse, SDL_DoSomethingElse, c_int)

[Skrylar]

@sfackler It wasn't clear that multiple impl blocks with identical signatures would mix without issue, so I thought you were suggesting generating the entire implementation block for the type in one function.

If having multiple implementation blocks is acceptable behavior, I recommend the reference manual mention this. I just re-checked and this is not mentioned under 6.1.9

[huonw]

@Skrylar fwiw, generating the entire impl block in one macro isn't necessarily crazy, e.g. the compiler does it in this macro, creating this impl with some generated methods. (Of course, you may have a design that's not amenable to this set-up, in which case, ignore me.)

[hugoduncan]

As far as I can tell, this doesn't work for pub fn in impls.

macro_rules! defn {
    // A match without return type
    ($n:ident) => (
            // Adding pub here results in: 
            //   error: expected one of `extern`, `fn`, or `unsafe`, found `pub`
            /* pub */ fn $n (&self) {
              println!("hi");
        })
}

pub struct Struct;

impl Struct {
  // Adding pub here doesn't give an error, but the
  // function ends up not being public.
  pub defn!(f);
}