Closed shepmaster closed 4 years ago
This is a known limitation. As the docs say. :-)
Note that this macro doesn't support mut or patterns in parameters.
cc @bluss (The original author of this amazing hackery.)
(I will also give this some thought, but I'm pretty deep in other stuff at the moment.)
Yes it can, but it's one of those tt-munchers. I extended it to do this after I showed the macro to burntsushi.
What the macro is doing: Counting :
tokens, one :
per function argument.
As the docs say
I'm not sure what you mean; what are these "docs" you speak of? 😵
In my (weak) defense, I was basically just grabbing the example from the README, so I never got into the docs at this particular time.
@bluss Do you know if that macro is backward compatible with the one we have now? If so, I'd happily merge it. (I will also get around to it myself... eventually.)
Sure, it is compatible. It's using as fn(_, _) -> _
for the function pointer cast, so if it would be something it would be a type inference regression. But I don't think it happens, that cast always seems to work with just _
for the arguments and return value.
Maybe the allowed attribute use is a bit confusing (you write it on top of the prop function, but it gets used on top of the #[test] function). It works well for conditional compilation, though, that way.
Adding onto this: it'd be nice if we recoded the macro using proc_macro
so that it unbreaks all of these changes. Additionally, the attribute could be made stable using macros 1.2.
@clarcharr That seems reasonable if it's possible. A few considerations:
As someone who uses this crate all over the place I would benefit from this :)
If this is still a problem, then I'd welcome a PR if it's fixable.
This currently fails:
My macro-fu is weak, any idea how difficult that would be to add?
As a workaround, I can always immediate rebind the variable, but I'm lazy! 😼