There have been many requests for supporting 3rd party crates such as: time, rust_decimal, uuid, and chrono. Rather than implementing support manually for these crates and more, an easier solution is to allow types implementing serde::Serialize inside types implementing bitcode::Encode.
This was previously a feature in 0.5, but we didn't reimplement it in the 0.6 rewrite due due to technical limitations. I have since found a path forward and intend to add this feature to 0.6.
The downsides of using serde instead of implementing these types in native bitcode are:
- Worse performance
- Requiring
#[bitcode(with_serde)] annotations on every field where serde is used
- Doesn't work well on collection types since it forces everything inside them to use serde
1 and 2 aren't much of an issue if serde is used infrequently. 3 poses more of an issue, but so far none of the types requested are collections. We could mitigate it by implementing some of the popular collections such as IndexMap.
There have been many requests for supporting 3rd party crates such as: time, rust_decimal, uuid, and chrono. Rather than implementing support manually for these crates and more, an easier solution is to allow types implementing
serde::Serializeinside types implementingbitcode::Encode.This was previously a feature in 0.5, but we didn't reimplement it in the 0.6 rewrite due due to technical limitations. I have since found a path forward and intend to add this feature to 0.6.
The downsides of using serde instead of implementing these types in native bitcode are:
#[bitcode(with_serde)]annotations on every field where serde is used1 and 2 aren't much of an issue if serde is used infrequently. 3 poses more of an issue, but so far none of the types requested are collections. We could mitigate it by implementing some of the popular collections such as
IndexMap.