-
So they have the same convenience as macro_rules. It makes sense to give people the option to break things out into separate crates as things get large, but there's no real need for that to be the default.
I'm not sure if this is still the case, but the original reason to have them be separate crates was because they needed to be dylib instead of rlib
-
-
Also makes sure that code which is only called by proc macros isn't included in the final binary (yes it will probably get cleaned up by DCE, but if it's a library having something `pub` isn't dead, and it's just adding more work for LLVM, therefore slower build times)
-
Yup! There are definitely potential downsides, but I don't think that changes whether we should have it or not. Const functions can already be evaluated at compile time in the same crate without needing to be dynamic libraries.
- 1 more reply
New conversation -
-
-
I'd wager the "needs to be dylib" requirement is still true since the compiler does in fact have to load them dynamically
-
I assumed this goes away when you require them being const fn -- which started this. So you use a different mechanic to evaluate them at compile time
- 4 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.