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

Allow rename_all_fields for structs as well as enums #2832

Open
bmwebster opened this issue Oct 3, 2024 · 0 comments
Open

Allow rename_all_fields for structs as well as enums #2832

bmwebster opened this issue Oct 3, 2024 · 0 comments

Comments

@bmwebster
Copy link

bmwebster commented Oct 3, 2024

It could be useful if the following code worked:

#[derive(Debug, Serialize, Deserialize)]
#[serde(rename_all_fields = "camelCase")]
struct CaseTestStruct {
    case_test: i32,
}

Currently this produces a macro error error: #[serde(rename_all_fields)] can only be used on enums.

Allowing use of rename_all_fields would give greater consistency - to me it seems that the operation "rename all fields" applies just as well to plain structs as to struct variants in enums.

This would mean we could use the same attribute for structs and enums to get a reasonable javascript compatible renaming, using PascalCase variant names (no renaming from Rust) and camelCase field names. This would make it easier to explain to other team members new to Serde, and reduce the risk of accidentally renaming enum variants since we wouldn't have to use rename_all anywhere.

One use case that would be very useful for me would be when using prost to generate structs and enums from protobuf. prost allows adding annotations to generated structs and enums, but the same annotation must be used in all cases.

It seems like this wouldn't be a breaking change, since it wouldn't change the behaviour of any existing error-free code, it would just allow code that would previously have produced an error to compile?

One alternative for my use case would be a proc_macro_attribute that operates on data and applies different serde attributes depending on whether the data is an enum or struct, but it seems a shame that's necessary. We'd probably implement the macro to accept a "style" (e.g. a style could represent "PascalCase enum variants, camelCase fields, tag = type" to use one common approach) that could then set other attributes like tag = "type" on enums - not sure whether that's something serde could eventually have to allow for more compact attributes that aim for a common combination of renaming settings?

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

No branches or pull requests

1 participant