Ah I was thinking about "keep things allocated where they were before, but try to dynamically dispatch implementation code, to avoid compiling it N different times." It sounds like you're talking about "heap allocate everything by default." If everything was implicitly boxed, no type could be `Copy`, right? Is that strategy possible without breaking existing code?
You can Box Copy types, yes, but the result is !Copy. So for example, maybe I have a slice of ints, and I'm calling ptr::copy_nonoverlapping on that slice. (Maybe via safe code, like slice::copy_from_slice.) That no longer works; I need new heap allocations for each int. And my slices of ints no longer have a memory layout that's compatible with C, so all ffi breaks?
Is it a goal of production vs debug build that the data structures that you define in your program are always the same?
I could see some kinds of funny differences in behavior between debug / production builds, if for a debug build a particular thing is boxed, but in production it isn't.
If it's a program-visible kind of box, yes that would be a problem.
But if you're generating polymorphic dispatch code at a lower level than expressible in Rust itself, there is no reason why hidden box types cannot be used to simulate unboxed types. That's just a memory representation difference. A bit like the way V8 creates specialised types for JavaScript objects at run time, but it's invisible to JavaScript except for speed.
The trouble is that the memory representation is fixed and observable in many cases. If you have arrays of primitive or repr(C) types, those are guaranteed to have the same contiguous layout as an array in C would. In particular, you often need to pass pointers to those things to actual C code. Copy types are similar; even if you can't necessarily assume all the details about their layout, you can copy them byte for byte and assume the result is valid. But that doesn't work if the compiler secretly inserts an owning heap pointer that needs to remain unique. The compiler could try to deduce when the memory layout is actually observed in practice, and do whatever it wants in cases where it can prove the difference doesn't matter, but I feel like that would end up making everything more complicated rather than less.
