redundant_closure_call false positive in macros

[tormol]

Is there a better way to delegate the body of a method to a parameter?

[kornelski]

I've ran into the same problem. I use a closure in a macro to work around macro hygiene and pass variables to an expression provided by the macro caller.

macro_rules! … {
…
    for (s,d) in src.iter().zip(dst.iter_mut()) {
        ($fix)(s,d);
    }
…
}

[oli-obk]

I think it would be fine to simply not trigger the lint inside macros.

Note that you can write this without closures, by passing in the names of s and d as $s:ident and $d:ident to the macro. This should result it the same amount of code written at the macro invocation.

[Kixunil]

Hit this right now. Yes the macro could be rewritten to do it differently but I believe that passing a closure to macro is the most readable way to write it.

This problem can be bypassed by writing (($closure))(args) (use double parentheses) but making the lint saner should still be considered.

[jpmckinney]

Note that you can write this without closures, by passing in the names of s and d as $s:ident and $d:ident to the macro. This should result it the same amount of code written at the macro invocation.

So would this be something like:

macro_rules! mymacro {
    ( $s:ident, $d:ident, $fix:expr ) => {
…
        for ($s, $d) in src.iter().zip(dst.iter_mut()) {
            $fix;
        }
…
    };
}

where $fix (which as a closure might have been |s, d| ...) just becomes the ... part?

I believe that passing a closure to macro is the most readable way to write it.

I agree, this:

mymacro!(..., (|s, d| s + d))

is easier to read than:

mymacro!(..., s, d, s + d)

(especially as the s + d expression becomes longer, and as the number of arguments increases).

This problem can be bypassed by writing (($closure))(args) (use double parentheses) but making the lint saner should still be considered.

This worked for me, except because cargo fmt removes the doubling, I add one set of parens in the macro definition and another set of parens in the macro call.

[kupiakos]

this:

mymacro!(..., (|s, d| s + d))

is easier to read than:

mymacro!(..., s, d, s + d)

(especially as the s + d expression becomes longer, and as the number of arguments increases).

@jpmckinney That's not the only way to refactor the macro. It could be rewritten to (scalably) take mymacro!(..., (s, d) => s + d) with ($($params:ident),*) => $fix:expr or even a closure-like syntax with |$($params:ident),*| $fix:expr.

[Kixunil]

@kupiakos note that if you rewrite the macro to always take closure syntax then you can't pass in function pointers. Allowing any callable expression is best and the lint should be fixed.

[m-rph]

Fixed through #12082