I just want the flag to say "I'll write all my code the monomorphizable way but I'll take smaller code at the cost of worse performance so please treat all my generics and impl Traits like they're dyn".
...because @rustembedded
-
-
I don't think having an all-or-nothing switch would be super helpful. I wish it was. There are specific situations where monomorphization isn't bad for code size because it enables the kind of inlining that reduces binary size and vtables aren't free.
1 reply 0 retweets 0 likes -
Yeah sure, but a `-s` option to signal a preference for smaller code size over better performance would be nice.
2 replies 0 retweets 2 likes -
Via an interpreter?
1 reply 0 retweets 0 likes -
Miri?
1 reply 0 retweets 0 likes -
Yeah, presumably a modified Miri that would use real memory instead of an abstract heap.
1 reply 0 retweets 0 likes -
Another option would be a Cranelift IR interpreter.
2 replies 0 retweets 1 like -
I've been thinking for a while that this could just be a lint: "changing this generic bound to `dyn` will cause X% compilation speedup and Y% reduction in binary size with ~Z% performance impact". There's no reason for every Swift implicit change cannot be an explicit Rust lint.
2 replies 0 retweets 4 likes -
Using trait objects is way more valid than the current usage in the ecosystem implies.
2 replies 0 retweets 5 likes -
I'd love to write a blog post about this. I think I have some cool trait object usage patterns that are underexplored, like &dyn Into<T>
1 reply 0 retweets 11 likes
Ohh, yes please! Would def read.
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.