That’s beautiful, in a special way.
Is Vec that important to Rust? (I’m not a Rust programmer). Are there no other container types that we might need to serialize, each with their own memory representation? It seems a lot of effort to go to for something that only marginally improves performance for one particular type.
And the view exposed is a less-than-complete Vec Is there no interface that represents a fixed-size, read-only sequence? If that’s what we want to serialize and deserialize with zero copy, wouldn’t it be better to represent that as a type? (And the “entombment” step could be turning the memory of a Vec into one of these things, which seems like better separation of concerns).
Vec<T> is just the heap-allocated list-of-stuff type provided by the standard library. It’s a very common type to use, but not the only one. You’re correct that other types would need different things. There is one subtlety here though: because Vec heap-allocates a bunch of contiguous bytes, if you want to be hacky about it, you can consider it a poor person’s malloc. So after doing this for Vec, you could (in theory) treat that other structure as a bag of bytes, and cast it to a Vec… Even more hacks on top of this already hacky concept!
So, nothing truly represents read-only in Rust. Mutability is a property of a binding, not the structure itself, and so you can make a particular stucture mutable or immutable, depending. There is a fixed-size array type, but it’s a bit awkward to use right now, because each length is its own type. When we gain support for type-level integers, they’ll get much nicer to use.