The beginning led me to think that this might be talking about something like Cap’n’Proto where the format is made in such a way where you can work with in in-memory without any (de)serialization. Though, formats like that have some toughness to deal with, like the fact that Cap’n’Proto needs to have 5 different types of pointers to be able to be encoded efficiently while being easily modifiable in memory.
Not quite, Cap’n’Proto is regular zero-copy deserialization (and the previous post in this series talks about zerovec, a crate that brings this to Rust’s serde framework). Cap’n’proto (and zerovec + serde) still require a validating deserialization step, it’s just cheap. You could skip the validation but that would potentially be a vector for memory unsafety.
This has no validation required, ever, with the tradeoff that you have to bake it in to your binary.
And on the plus side, it is far more flexible in what kinds of types it supports since stuff just has to be const constructible.
The beginning led me to think that this might be talking about something like Cap’n’Proto where the format is made in such a way where you can work with in in-memory without any (de)serialization. Though, formats like that have some toughness to deal with, like the fact that Cap’n’Proto needs to have 5 different types of pointers to be able to be encoded efficiently while being easily modifiable in memory.
Not quite, Cap’n’Proto is regular zero-copy deserialization (and the previous post in this series talks about
zerovec, a crate that brings this to Rust’s serde framework). Cap’n’proto (andzerovec+serde) still require a validating deserialization step, it’s just cheap. You could skip the validation but that would potentially be a vector for memory unsafety.This has no validation required, ever, with the tradeoff that you have to bake it in to your binary.
And on the plus side, it is far more flexible in what kinds of types it supports since stuff just has to be const constructible.