Idea: Declarative custom `derive`s and attributes

language design
1

Sometimes we don't need the power of procedural macros but still want to express declarative macros as derive for some trait, or some custom attribute. This could help with compile times.

A very common custom attribute I see used is tokio::main. It doesn't need to be a procedural macro, but it is because attributes must be procedural.

7 Likes
2

While I agree that this would be great, I think we should focus on macros 2.0 (the macro foo {} ones) before introducing even more things. Hygiene would be quite important for this, I would think.

5 Likes
3

It's worth noting that it would be possible to prototype this partially out of tree.

There's sort of two parts to it that could be done:

  • Declaring the attribute itself: this can be prototyped as a macro implementing declarative syntax to implement the proc macro API.
  • IDE benefits: using an auxiliary table in the cargo manifest, or maybe just recognizing the above generation tool, it would be possible to allow rust-analyzer to expand such declaratively definable macros directly rather than going through the proc macro runtime, with all the downsides that puts on the IDE use case.

But otherwise I agree that full macros 2.0 hygiene is important to get right first; we'd want any new macro surface area to have the 2.0 hygiene if possible.

4

I'd rather push for

's #[apply] and/or #[macro_rules_derive(…)] attributes to be made built-in attributes, and you'd have all these things for free. Until then, using one helper crate isn't that big of a deal either (it doesn't use syn so it compiles as fast as a proc-macro crate can compile)

3 Likes
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.