This removes the rkyv feature and all the trait implementations that came with it.
The deserialization world contains various frameworks, each coming with their own strengths and weaknesses. It can be argued that it is too opinionated to support one over the other for a library.
Additionally, adding the code bloat of implementing traits for all types and their entire contained data is pretty much always overkill. Chances are users would only need support for very few types. And even when handling those types, serialization can often times be significantly improved by ignoring all pieces of irrelevant data.
For people that depended on the rkyv feature, I recommend to look into the rkyv::with::{ArchiveWith, SerializeWith, DeserializeWith} traits which essentially allow trait implementations of rkyv::{Archive, Serialize, Deserialize} on remote types. The rkyv-with even provides a way to derive those *With traits.
This removes the
rkyvfeature and all the trait implementations that came with it.The deserialization world contains various frameworks, each coming with their own strengths and weaknesses. It can be argued that it is too opinionated to support one over the other for a library.
Additionally, adding the code bloat of implementing traits for all types and their entire contained data is pretty much always overkill. Chances are users would only need support for very few types. And even when handling those types, serialization can often times be significantly improved by ignoring all pieces of irrelevant data.
For people that depended on the
rkyvfeature, I recommend to look into therkyv::with::{ArchiveWith, SerializeWith, DeserializeWith}traits which essentially allow trait implementations ofrkyv::{Archive, Serialize, Deserialize}on remote types. Therkyv-witheven provides a way to derive those*Withtraits.