Skip to content
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

Introduce empty_as_none and empty_as_none_vec deserializers #23

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Turbo87
Copy link
Contributor

@Turbo87 Turbo87 commented Dec 18, 2024

This commit changes the way foo= is deserialized into Option<_>. Previously it was deserialized as None, now it will be deserialized as Some(_), unless the new empty_as_none deserializer is used via #[serde(deserialize_with = "crate::de::empty_as_none")]. This allows users to decide on the deserialization strategy on a field-by-field basis.

Resolves #13

@Turbo87
Copy link
Contributor Author

Turbo87 commented Dec 18, 2024

@jplatte I've kept this as a draft PR since it does not contain documentation yet, but I'm curious whether you think this is a direction worth continuing :)

This commit changes the way `foo=` is deserialized into `Option<_>`. Previously it was deserialized as `None`, now it will be deserialized as `Some(_)`, unless the new `empty_as_none` deserializer is used via `#[serde(deserialize_with = "crate::de::empty_as_none")]`. This allows users to decide on the deserialization strategy on a field-by-field basis.
@Turbo87
Copy link
Contributor Author

Turbo87 commented Jan 15, 2025

any more thoughts on this? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change behavior for empty values when deserializing an option
1 participant