3 ms·
yeah, lets be clear: Most of the proc macros non-sense is to be able to annotate the enum or struct without wrapping it. So that is why I use this hack: http
by mamcx 4mo ago
yeah, lets be clear:
Most of the proc macros non-sense is to be able to annotate the enum or struct without wrapping it.
So that is why I use this hack:
https://docs.rs/macro_rules_attribute/0.2.2/macro_rules_attribute/ https://docs.rs/macro_rules_attribute/0.2.2/macro_rules_attr...
P.D: Is there a true actually reason for proc-macros apart for this weird restriction?? And even if yes, how much nice things will be if this kind of scenario was already present so most not need to reach for proc-macros
- Sagi21805 4mo agoThat's really cool, I was not familiar with this and will look into it!
- mmastrac 4mo agoTypes and generics are hard to parse in regular macros without a tt muncher. Ditto for fn args. If you need to do actual matching of types, you can't capture them as $xxx:ty because Rust will not allow a larger matched token to be broken up again (unless you use a paste! hack to roundtrip it back into ungrouped tokens). I wrote https://crates.io/crates/type-mapper https://crates.io/crates/type-mapper as a way to work around those limitations but it is _very_ painful TBH.
- afdbcreid 4mo agoWhat this crate offers was RFC'd somewhat recently (https://github.com/rust-lang/rfcs/pull/3698 https://github.com/rust-lang/rfcs/pull/3698, https://github.com/rust-lang/rfcs/pull/3697 https://github.com/rust-lang/rfcs/pull/3697) and already available on nightly.