-
Notifications
You must be signed in to change notification settings - Fork 176
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
Write custom deserializer function for Option<Cow<str>> #821
Conversation
Codecov Report
@@ Coverage Diff @@
## main #821 +/- ##
==========================================
+ Coverage 75.34% 75.44% +0.09%
==========================================
Files 197 193 -4
Lines 12563 12499 -64
==========================================
- Hits 9466 9430 -36
+ Misses 3097 3069 -28 Continue to review full report at Codecov.
|
Pull Request Test Coverage Report for Build 1e77bd4636ba5acea5377d8af8f385012fd077ad-PR-821
💛 - Coveralls |
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 opinion on where this should go. Probably worth making it a public export of provider/core? Other data structs will need this, yes?
use std::borrow::Cow; | ||
use std::fmt; | ||
|
||
fn deserialize_option_cow_str<'de, D>(deserializer: D) -> Result<Option<Cow<'de, str>>, D::Error> |
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.
chore: Probably should have a comment saying why we have this
I can stick it in the icu_provider module, but I'm just a little hesitant to start making icu_provider a bag of random utilities. But maybe there just isn't a better place to use it, and most call sites that need this will be depending on icu_provider. |
Yeah I don't have a good answer for you, I don't have strong opinions on where it should go so use your best judgement imo. |
2021-06-24:
|
I think upstreaming this is going to be unlikely and for now we should just stick this in provider_core. |
Acknowledged, but I made a PR for upstreaming this anyway: It should be noted that this only affects serde_derive, not serde itself. |
So we may not end up needing this in the short-term because PluralRules is going to be migrated off of |
I need this in #1550, so let's merge? We could put it alongside |
Superseded by #1556. |
Workaround for serde-rs/serde#2016
@Manishearth: opinions on where this should go?