-
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.
-
Right, but const fns can't change the actual code being called by other const fns
End of conversation
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.