Man, I did a bunch of work getting this whole extra crate just for one proc macro working to extract nested function ASTs from rust files,<p>and on the 2nd day of work after everything finally worked, it complained because I wanted to return the AST instead of a token stream.<p>Joke’s on me because I didn’t know you have to use proc macros to transform code and I wound up just rewriting it as a function. Hopefully that doesn’t screw up what I want to do, which is basically compile time correctness checking, but it probably will…<p>Feels like every time I try to make compile time functionality in rust, I wind up getting sucked into endless type-level shenanigans, and it works, as long as you can tolerate the error messages being nigh unreadable.<p>WTB “comptime” Rust
Given the conclusion that a painfully large amount of time is spent re-evaluating procedural macros and that this was largely mitigated by adding a cache, it would seem as if the linked discussion about "const" macros on the Rust language design forum is incorrectly analyzing the near-term need for deploying such a feature: they are concentrating on security use cases (which frankly seem a bit dubious to me) or (this one I hadn't heard before but is in the thread) changing where they are packaged (which, to those of us in the peanut gallery wearing our separate compilation hats and prototype fan club hoodies, seems like a far-too-entrenched mistake in Rust's design to bother fixing at this level) whereas being able to safely and automatically know which macros can be cached and which ones can't be (particularly as I'd pray that the big listed use case from the article of a non-const macro--including a file as bytes--either already isn't slow or clearly should be trivially fixed to not be slow) seems to be the real banner feature of having const macros be standardized.