You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, thanks for this awesome library! I have some questions regarding in-place deserialization.
I'm wondering why we are filling skipped fields in deserialize_in_place(). Skipped fields are ignored for maps but not for sequences. Is there a reason for it or should the filling with default be removed? This is the relevant code that writes default values into the in-place struct:
My use case is the following: I have a struct (MixedContent below) which contains fields that I want to serialize and fields that cannot be serialized and also don't implement Default. Something like this:
// serde_derive with Feature deserialize_in_place#[derive(Deserialize,Serialize)]structMixedContent{#[serde(skip, default = "panic")]non_serializable:NonSerializable,serializable:Serializable,}fnpanic() -> NonSerializable{panic!("deserialize not implemented")}structNonSerializable{// ...}#[derive(Deserialize,Serialize)]structSerializable{// ...}
Since I cannot implement Default for the NonSerializable but for Serializable, my idea was to use the deserialize_in_place functionality with skipped fields. With that I can create a custom constructor with more fancy logic and then use deserialize_in_place() afterwards on the struct. I think, using some DeserializeSeed is too complicated because it seems I need to implement it manually. Also custom home-grown derive macros doesn't feel right to achieve my scenario.
What I need to adjust from basic serde usage is
Generate a proper deserialize_in_place: Easy, just enable the feature flag
Disable the normal deserialize: Can be done via a serde(default = ...) attribute which never returns anything but fulfills the trait and makes the compiler happy
Deactivate all struct field writes of skipped fields: Doesn't work because the sequence code generation still contains them, see above
I'm willing to create a PR to remove the skipped field filling in sequences but wanted to make sure, nothing else gets broken by it (Chesterton's Fence). Do you have suggestions?
The text was updated successfully, but these errors were encountered:
Working with skipped fields are broken in many cases, I'm working right now on fixing those issues and will make a PR in a few days.
But in this case that is never-mind. I do not plan to change this behaviour in my PR. Although I agree, that it will be better to does not touch missing fields.
Hi, thanks for this awesome library! I have some questions regarding in-place deserialization.
I'm wondering why we are filling skipped fields in
deserialize_in_place()
. Skipped fields are ignored for maps but not for sequences. Is there a reason for it or should the filling with default be removed? This is the relevant code that writes default values into the in-place struct:serde/serde_derive/src/de.rs
Lines 805 to 810 in 03da66c
My use case is the following: I have a struct (
MixedContent
below) which contains fields that I want to serialize and fields that cannot be serialized and also don't implementDefault
. Something like this:Since I cannot implement
Default
for theNonSerializable
but forSerializable
, my idea was to use thedeserialize_in_place
functionality with skipped fields. With that I can create a custom constructor with more fancy logic and then usedeserialize_in_place()
afterwards on the struct. I think, using someDeserializeSeed
is too complicated because it seems I need to implement it manually. Also custom home-grown derive macros doesn't feel right to achieve my scenario.What I need to adjust from basic serde usage is
deserialize_in_place
: Easy, just enable the feature flagdeserialize
: Can be done via aserde(default = ...)
attribute which never returns anything but fulfills the trait and makes the compiler happyI'm willing to create a PR to remove the skipped field filling in sequences but wanted to make sure, nothing else gets broken by it (Chesterton's Fence). Do you have suggestions?
The text was updated successfully, but these errors were encountered: