Open caibear opened 1 month ago
Downside 4: serialize
returns a Result
, so encode
would either have to return a Result
(breaks compatibility with 0.6
) or panic on Err
from serialize
.
Still in favor of this, though!
Implementing this would partially-fully resolve these open issues:
serde_repr
to serialize enum as u16bitcode::Encode
typesI would like to ask if we use #[bitcode(with_serde)
for example with uuid::Uuid
, do we get to choose which representation we want (something similar with {de}serialize_with
) because I think most people will want to encode an Uuid
with u128
instead of a str
(no one will open the bitcode message to read anyway :D).
most people will want to encode an
Uuid
with [bytes] instead of astr
The correct choice is made automatically, considering uuid
checks whether the format is human readable. bitcode
is not human readable, so uuid
uses raw bytes.
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 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
.