-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Greatly reduce amount of generated code #1
Conversation
|
||
#[allow(missing_docs)] | ||
#[inline] | ||
fn to_custom(&self) -> CustomSerializerOptions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this not be a impl<T: SerializerOptions> From<T> for CustomerSerializerOptions {}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(and same for the DeserializerOptions
?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a conflict with the default implementation impl<T> From<T> for T
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries then. Oh boy the day Rust gets partial specialization I will be very happy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the new generics, though some might actually lead to more code getting generated in some points (if code factorization fails, which it shouldn't for such simple cases).
Have you measured the impact on binary size? (not that I feel the need for that to approve, just curious :) )
cargo_bloat measurements courtesy of @frankie Before
After
|
Co-authored-by: Frankie <[email protected]>
As promised, performance evaluation with
|
Fixed the big regression in 1b274f7 and further improved the rest.
|
Why private-fork an unmaintained crate
serde_cbor
is unmaintained, it's stable. We have almost all ditto serialization to attest to that. Even at the time of archival, there weren't any real bugs open other thanOption<()>
handling.Changes
serde_cbor
are compatible at the lower level. At the higher level (structs/enums/..), compatibility is ensured by passing all the same tests and also not touching the code.ucbor
, which is highly optimized for speed and size.serde_cbor
. This includes the nuances of modeling structs/newtypes/enums atop of the serde data model.Breaking changes
Theoretical breaking change
deserialize_str(visitor)
but would produce a value if the visitorvisit_u64(..)
was called. That is incompatible with this fork.