Add alias_all attribute for containers similar to rename_all

[dmarcuse]

The rename_all attribute is very handy for cases where you have fields named in ways that don't follow Rust conventions. However, there are cases where you might want to support both ways - for example, loading data with support for both naming conventions, but preferring a different naming convention for saving that data later. I propose that an alias_all container attribute be added that functions similarly to rename_all, so that a struct like this...

#[derive(Serialize, Deserialize)]
#[serde(alias_all = "PascalCase")]
pub struct MyStruct {
    string: String,
    bool: bool
}

...can be deserialized from JSON like this...

{"String":"hello world","Bool":true}

...but will still be serialized like this:

{"string":"hello world","bool":true}

[DzenanJupic]

Following up on https://github.com/serde-rs/serde/pull/1972#issuecomment-929907819

Has the moratorium on new attributes been lifted (or will it ever be)? If new attributes are accepted again, this branch [diff] would contain an implementation compatible with the current master. If compile time is still the biggest concern, maybe a solution is to feature gate (new) attributes.

For everyone else stumbling over this, while searching for a solution myself, I found serde_alias.

[filipdutescu]

I would also love to have something like this. Have a config which uses kebab-case and should support overriding from env vars. This is not possible with current options (as far as I can tell), unless I want to spend a large effort creating my own deserializer - which is a bit outside my time budget.

Are there any plans for this feature/a similar one? Or maybe some workarounds I could use in the meantime?

[blinsay]

I would also love to have alias_all. I'm parsing some data structures that get produced in either snake_case or camelCase and this would be extremely handy. Right now I'm stuck adding alias attributes by hand to every field/variant in my data.

I peeked at serde_alias, but I'm hesitant to pull it in (or write my own) because it seems like the execution order of proc-macros is undefined.