11–20 of 21 posts
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
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_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
for d: Option in data {
let val: i32 = match d {
Some(v) => v,
None => break
};
// Other stuff
}
I'm really confused by the unwrap_or_break example in this text. The article says it wouldn't be possible to do without a macro, but how is it not equivalent to for d: Option in data { let val: i32 = match d { Some(v) => v, None => break }; // Other stuff } As far as I can tell that would do the exact same thing as the macro example.
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
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_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 reac…
I'm really confused by the unwrap_or_break example in this text. The article says it wouldn't be possible to do without a macro, but how is it not equivalent to for d: Option in data { let val: i32 = match d { Some(v) => v, None => break }; // Other stuff } As far as I can tell that would do the exact same thing as the macro example.
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
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_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 reac…
I wrote https://crates.io/crates/type-mapper as a way to work around those limitations but it is _very_ painful TBH.
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
It's interesting seeing this discussion in Rust because it's the same discussion that's been happening around macros in Scheme for decades. It's one of those things where there probably is no universal correct answer, so might as well allow both in your language and let the programmer decide what's best for their case.
A macro like (logged-fn) that defines a function which logs the arguments passed, is wonderful.
But if you see a macro like (validate-report), something very wrong happened.
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
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_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 reac…
As someone who has spent a _lot_ of time writing declarative and procedural macros, the important thing to ask before digging into a macro is whether you need a procedural macro at all. Complex proc macros absolutely do slow builds down. In many cases, a proc macro only need to be a stub that can delegate to a declarative macro. You may not need to use syn/quote, but if you are doing any sort of processing/parsing of…
If you can skip `syn` or `quote` by this, for sure do it (although they probably will be included anyway by other crates). But if not, it's not worth a lot.