What if macro methods

language design
1

what if like

as a simple example

struct Foo {
  x: i32,
  y: i32
}

impl Foo {
  fn new(x: i32, y: i32) -> Self {
    Self { x, y }
  }
  macro_rules! scale {
    ($self:expr, $z:expr) => {
      Foo::new($self.x*$z, $self.y*$z)
    };
  }
}

let f = Foo::new(2, 6);
let g = f.scale!(5);
/* let g = Foo::scale!(f, 5); */
/* let g = Foo::new(f.x*5, f.y*5); */

this would be cool and epic and sick and wouldn't interfere with existing features as far as i can tell.

2

I've worked on postfix macros at https://github.com/rust-lang/rfcs/pull/2442

The idea of making them part of method dispatch, such that they depend on the type of the LHS, would be a much more complicated proposition, because we generally need to fully resolve macros before we have enough information for type dispatch. It's possible to solve that, and there are research languages that solve that, but it'd be a much harder problem.

The approach I used in RFC 2442 was instead to not care about types, just as existing macros don't care about types. (That still leaves room in the future for macros that care about types, whether postfix macros or regular macros.)

8 Likes
3

Can you say which properties of macros you're interested in here? Do you really want to do macro-like things in them (which depend on the passed-in tokens, or do caller-control-flow-affecting things), or are you just trying to value-like things without needing to write types?

It doesn't help that you appear to never use $z so I don't know what you mean by it.

If you mean the latter, see also the conversations about a hypothetical "macro fn", like Make macro syntax similar to function - #4 by scottmcm

5 Likes
4

i made two back-to-back typos whoops

    ($self:expr, $z:expr) => {
-     Foo::new($self.x*$self.z, $self.y*$self.z)
+     Foo::new($self.x*$z, $self.y*$z)
    };

the aspect that appeals to me the most is being able to define a DSL-y custom syntax. i'm using macro_rules! for this example but ideally a proc macro would also be possible... somehow. i don't think the whole "proc macros need to be in a seperate crate" works well with being in the middle of an impl block, but i don't have any good ideas atm

consequentially this is interesting in its own right but not precisely the same as what i'm suggesting

5

I don't think that's a very good motivating example. I'd help if you were able to provide an example where you really want dsl syntax in a method call.

I'm gonna go ahead and say that the standard matches! macro would be really neat as a postfix macro: a.matches!(Some(Ok(1))). Adding method scoping to a specific type seems like it'd require a pretty dramatic amount of changes to the compiler, for seemingly very little benefit.

3 Likes
6

We can have a separate macro role, called like expression macro that consumes the whole expression token chain prior to its invocation and the arguments to produce token chain that matches expr. -> so that a.method().call!(argument).other_method() is equvivalent to call!(a.method(),argument).other_method()

7

Was other_method! a typo or should this be:

other_method!(call!(a.method(),argument))

And would this have a trailing comma for the "no arguments" case?

1 Like
8

It was a typo. The no arguments case i think should have comma in the desugaring - simplifies the matching code?

9

I agree that the comma should be unconditional. Thanks for the clarification.

10

This design has been proposed before.

I know of two arguments against that:

  1. it can result in confusing behavior when the macro doesn't use the $self argument exactly once, because that part is syntactically not inside the macro, but is still affected by it.

    a.field
    .method(argfunc())
    .maybenot!()

    could possibly not call method or even argfunc(), without an obvious syntactic marker of that happening.

  2. the macro would have to be resolved based on the type of the receiver, which may run into type checking issues (macros are currently expanded before types are checked)

    mod a {
    pub struct A;
    impl A {
        macro_rules! bad {
            ($self) => {
                use b::A;
            }
        }
    }
}
mod b {
    pub struct A;
    impl A {
        macro_rules! bad {
            ($self) => {
                use a::A;
            }
        }
    }
}

use a::A;
fn main() {
    A.bad!(); // What is A here?
}

    playground

    This can probably be fixed, but it is far from trivial to do.

Instead, what I think would be more feasible:

  • Make method macro resolution independent of receiver type -- use normal name resolution instead.

    This avoids issue #2, but comes with these limitations:

    • method macros have to declared outside of impl blocks, "polluting" the namespace more than they should (because Rust does not have a global namespace, this is less of an issue)
    • method macros can not be "overloaded" based on receiver type

  • Evaluate the receiver expression exactly once regardless of the macro. Bind its result to an unnameable temporary variable. Make the $self argument of the macro refer to that variable.

    This would fix issue #1.

    • this does not allow the macro to inspect or modify the receiver expression.
    • I'm not sure what scope the temporary variable should have -- is it ok if it has normal variable scope or should it have some Special Scope™?
11

The combination of those two points (not caring about the receiver type, and evaluating the receiver expression exactly once) is exactly what Simple postfix macros by joshtriplett · Pull Request #2442 · rust-lang/rfcs · GitHub proposes.

4 Likes