Added `Custom` derive macro

[ModProg]

This allows using #[custom(...)] in macro_rules derive

9

[ModProg]

One thing I considered, but wasn't sure about, is deriving it by default with macro_rules_derive.

[danielhenrymantilla]

Nice idea (apologies for the late review); for what is worth, this is definitely mergeable, but I share your sentiment about directly integrating this into macro_rules_attribute.

The issue at that point would be that custom seems a tad too generic to add like this (potential collision with a genuine #[custom] macro)🤔

• what about #[derive_args(...)]?

Another option would be our #[derive()], once it has detected the custom Macro!s, to snake-case them (e.g., #[macro]) and make those inert.

That way:

#[derive(MyCustomDerive!)]
#[my_custom_derive(foo = "bar")]

would Just Work™

[ModProg]

Another option would be our #[derive()], once it has detected the custom Macro!s, to snake-case them (e.g., #[macro]) and make those inert.

The problem with that is, that IIRC there is no way to dynamically support custom attributes, this means, we would need to remove them manually from the struct, possible, but we need to be careful then to not remove ones that another derive macro needs.

The issue at that point would be that custom seems a tad too generic to add like this (potential collision with a genuine #[custom] macro)thinking

* what about `#[derive_args(...)]`?

We could also support multiple so that a user can just use the one they prefer/doesn't conflict, as rust doesn't have an issue with multiple derive macros sharing helper attributes.

[ModProg]

@danielhenrymantilla

We could also support multiple so that a user can just use the one they prefer/doesn't conflict, as rust doesn't have an issue with multiple derive macros sharing helper attributes.

If we go with that, what would be your preferred names? And should we derive it by default? We could put it behind an optional feature in case you don't want the probably very negligible overhead of deriving a macro, that does nothing in cases where it isn't used.

[danielhenrymantilla]

[hmm, I had missed the notification]

I guess #[custom] and #[derive_args] could be a baseline before thinking about others / I think those two would suffice 🙂

Anyhow, I'm definitely tempted to merge this already as is, but I'll let you add anything last-minute you may wish

• (don't mind that CI thing, it's a github runner regression which I need to cater to at some point)

[ModProg]

I guess #[custom] and #[derive_args] could be a baseline before thinking about others / I think those two would suffice slightly_smiling_face

Added derive_args.

What about deriving it by default?

[danielhenrymantilla]

Yeah, let's do it. I don't think the performance penalty will be noticeable, and it will be ergonomic 👍

[ModProg]

Yeah, let's do it. I don't think the performance penalty will be noticeable, and it will be ergonomic

yeah, it would only be a very small compile time hit.

@danielhenrymantilla This should now be ready for merge from my side.

[danielhenrymantilla]

Thanks @ModProg !