Also the whole "don't write macros" is such a hilarious statement given that entire Rust ecosystem is built on them.
> given that entire Rust ecosystem is built on them.
I don't think the people saying "don't write macros" are the same people building an entire ecosystem on top of them
The iced crate has virtually zero macros by design.
Declarative macros are very like regex's: both in that at first they seem incredibly dense and arcane but once you work out how to read them they're actually very simple, and in that the syntax is literally similar in that it's a list of tokens that must match sequentially.
C++26 reflection will make this much easier, without having to depend in stuff like the syn crate.
I wonder if going with two macro systems, each with its own syntax and approach, was such a good idea.
Sometimes the macros are for large chunks of code that uses a different type in a key place, or sometimes they're for cleaning up verbose function calls that will be made multiple times, so the important parts (e.g. the params) are obvious, instead of being mixed with boilerplate. In general, they're nice for papering over boilerplate. In particular, there's a pattern in embedded that involves a long expression with `try_into().unwrap()` for parsing bytes that I have a macro for. And another for managing RefCell<Mutex<Option>>> locks.
I prompt the LLM with the working, but repetitive or boilerplate-laden code, and it macros it: "Please write a macro that stops the repetition in this code block: ```rust ```. Here's a example of calling it: `do_thing!(a, b, c)`
Works every time!
Y_Y•1h ago
CaptainOfCoit•1h ago