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

Name equality checking with #[serde(name_eq = "..")] #2161

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

avitex
Copy link

@avitex avitex commented Jan 22, 2022

I put this forward as an alternative to #1902 allowing for a generic method of checking a field name on deserialization over a specific implementation tied to ASCII.

The provided name_eq container attribute can be be used for case-insensitivity.

// Note in this example we use ASCII case-insensitivity,
// but we could just as well use unicode case-insensitivity.
//
// We require `value` to be a byte slice as the deserializer
// may or may not provide us validated UTF-8.
fn eq_ignore_case(name: &str, value: &[u8]) -> bool {
    name.as_bytes().eq_ignore_ascii_case(other)
}

#[derive(Deserialize)]
#[serde(name_eq = "eq_ignore_case")]
pub struct Foo {
    // ..
}

Notes

  • NameEq/name_eq might not be the best name for this, but I wanted to put forward this initial implementation before bikeshedding.
  • I have not implemented this also as a field attribute but I see no reason that could not be the case in a future PR.

@avitex avitex changed the title Name equality checking Name equality checking with #[serde(name_eq = "..")] Jan 22, 2022
@avitex
Copy link
Author

avitex commented Jan 22, 2022

Now that I think about it, perhaps alias_with/alias_all_with could be a better name inline with deserialize_with and alias which is a loose idea of what this functionality actually provides.

#[derive(Deserialize)]
#[serde(alias_all_with = "case_insensitive")]
pub struct Foo {
    // ..
}

This could also provide a method of solving #1530

@avitex
Copy link
Author

avitex commented Mar 21, 2022

@dtolnay Any thoughts on the initial implementation or comments?

@0cv
Copy link

0cv commented Jan 22, 2023

Case insensitive keys is exactly what I've been looking for. It would be really great to get this merged if all is fine.

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

Successfully merging this pull request may close these issues.

None yet

2 participants