2 ms·
Wait, most uses of macros in Rust don't have much to do with memory safety. RAII and borrow-checking don't rely on macros at all. Most features of, e.g., serde
by ameliaquining 5y ago
Wait, most uses of macros in Rust don't have much to do with memory safety. RAII and borrow-checking don't rely on macros at all. Most features of, e.g., serde would work the same way in a garbage-collected language.
The primary exception that comes to mind is pin_utils::pin_mut, which is a macro primarily because of the somewhat circuitous route by which async came to Rust. If the language had been designed to support async from the beginning, I suspect that it probably would have been built-in syntax (assuming it didn't avoid the need for such an API entirely by using a different design).
- pjmlp 5y agoTry to use Gtk-rs without the clone macro, and it will be lots of fun handling callbacks and widgets relationships.
- ameliaquining 5y agoI wouldn't call this kind of macro idiomatic in non-GTK code. Reference counting is mostly used only occasionally in Rust code, and so the boilerplate cost of adding another local variable when giving a closure its own reference-counted pointer is outweighed by the maintainability cost of introducing a macro. gtk-rs is different because it pervasively uses Rust bindings to a non-Rust-based memory management system based on reference counting and interior mutability, kind of like if everything was wrapped in Rc<RefCell<T>>. In that scenario, yeah, adding another local in front of every closure capture sounds like a pain. If most Rust code were like this, I suspect that something like glib::clone would be added as built-in syntax.
- zarzavat 5y agoFor instance one of the most popular crates is the lazy_static macro without which it is hard to define global state. I also tend to define quite a few helper macros in my Rust code to keep clean.
- pornel 5y agoonce_cell does the same with a closure. Improved const evaluation has also eliminated some uses of lazy_static.