-
-
Why in-crate? Please explain like I'm that guy who turns every rust project at work into a workspace monstrosity
2 replies 0 retweets 3 likes -
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.
2 replies 0 retweets 1 like -
Replying to @Sunjay03 @killercup and
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
2 replies 0 retweets 0 likes -
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)
1 reply 0 retweets 0 likes -
Replying to @sgrif @killercup and
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 reply 0 retweets 0 likes
Right, but const fns can't change the actual code being called by other const fns
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.
