3 ms·
So, if you're writing in Rust, why not box everything, most of the time? Pay the cost of dereferencing to make it easier to reason about closures? Save unboxe
by sevensor 8y ago
So, if you're writing in Rust, why not box everything, most of the time? Pay the cost of dereferencing to make it easier to reason about closures? Save unboxed values for situations where they're either trivial to reason about or you're sure there's a performance problem? Is this regarded as bad form?
(I don't really know Rust, but I'm watching with interest. As my comment may suggest, I'm more familiar with C and Python.)
- glittery 8y agoUnboxed closures aren't any harder to reason about than boxed closures, and any function that accepts an unboxed closure accepts a boxed closure, too, which is why library authors should almost always prefer accepting unboxed closures (as withoutboats said in another comment.)
- steveklabnik 8y agoYou can. I'm not sure how much it's done or isn't done, really. Pre-1.0 Rust even had mandatory boxed closures, and until fairly recently (1.26?) you still had to box them in more situations than you do today.
- blt 8y agoI think the general philosophy of Rust is that programmers should think about the data ownership semantics of their programs. Rather than boxing everything to make it easier to reason about closures, one should strive to write programs that use closures in a way that is easy to reason about.
- int_19h 8y agoIf you intend to box everything most of the time, you might as well just use a higher-level language with GC, like C# or Swift.
- oleganza 8y agoBecause, contrary to what the OP is saying, writing normal Rust is actually easy and straightforward. So you don't have to "box everything" by default. You only need that when you do some asynchronous work via generic interfaces.