As an avid rust proc macro crate author, the zig macro example is quite humbling. I would welcome this kind of reflection and comptime stuff in place of (or more likely, in addition to) the existing macro systems (decl macros, and proc macros) that we have in rust.
Proc macros are particularly awkward because of the requirement that they must be defined in a separate proc macro crate. There are all sorts of things one could do if it were possible to instead make proc macros that generate proc macros _in place_ like one can with decl macros.
Then there is also the issue of macro expansion... the rustc framers openly admit that with an expression like foo!(bar!(..)) it is often preferable to have bar!(..) expand _before_ foo!(..) expands, because they have hacked in this behavior for several of the built-in macros like `concat!`, however this behavior is completely unavailable for custom macros. In fact, this one little issue is the ONLY blocker to all kinds of exotic and powerful behavior, the lack of which is holding the ecosystem back, for example the ability to eagerly expand a series of macro calls would enable the following things:
* the ability to determine the column, line, and source file in which a macro is being called, at compile-time
* the ability to determine the module path of the caller of your macro, at compile time
* the ability to determine the name of the crate in which a macro is being called, at compile-time
* the ability to implement complex compositional behavior purely in proc macros
* (very important) the ability to determine the `CARGO_MANIFEST_DIR` of the crate in which a macro is being called. Without this key ability, it is impossible to reliably determine where we are executing so we can do things like read metadata configuration values from _the caller's_ `Cargo.toml` at compile-time.
So yeah, really hoping at least eager expansion stabilizes sometime soon, but this zig stuff would be even better.
Proc macros are particularly awkward because of the requirement that they must be defined in a separate proc macro crate. There are all sorts of things one could do if it were possible to instead make proc macros that generate proc macros _in place_ like one can with decl macros.
Then there is also the issue of macro expansion... the rustc framers openly admit that with an expression like foo!(bar!(..)) it is often preferable to have bar!(..) expand _before_ foo!(..) expands, because they have hacked in this behavior for several of the built-in macros like `concat!`, however this behavior is completely unavailable for custom macros. In fact, this one little issue is the ONLY blocker to all kinds of exotic and powerful behavior, the lack of which is holding the ecosystem back, for example the ability to eagerly expand a series of macro calls would enable the following things:
* the ability to determine the column, line, and source file in which a macro is being called, at compile-time
* the ability to determine the module path of the caller of your macro, at compile time
* the ability to determine the name of the crate in which a macro is being called, at compile-time
* the ability to implement complex compositional behavior purely in proc macros
* (very important) the ability to determine the `CARGO_MANIFEST_DIR` of the crate in which a macro is being called. Without this key ability, it is impossible to reliably determine where we are executing so we can do things like read metadata configuration values from _the caller's_ `Cargo.toml` at compile-time.
So yeah, really hoping at least eager expansion stabilizes sometime soon, but this zig stuff would be even better.
Some of my crates that would benefit from this:
* docify: https://crates.io/crates/docify
* macro_magic: https://crates.io/crates/macro_magic
* crate-settings (non-functional until this comes out): https://crates.io/crates/crate-settings
* proc-utils: https://crates.io/crates/proc-utils