Open
Description
i.e. I would expect
#[derive(Display)]
#[display(rename="snake_case")]
enum Test{
First
}
println!("{}", Test::First) // -> prints "first"
The serde behaviour is documented here:
https://serde.rs/container-attrs.html#rename_all
#[serde(rename_all = "...")]
Rename all [...] variants [...] according to the given case convention. The possible values are "lowercase", "UPPERCASE", "PascalCase", "camelCase", "snake_case", "SCREAMING_SNAKE_CASE", "kebab-case", "SCREAMING-KEBAB-CASE".
Activity
Display
derive macro #225JelteF commentedon Nov 21, 2022
This sounds useful. It fits well with the FromStr for unit enum support that was introduced in #176.
bikeshed: I think I prefer
rename
overrename_all
. That way you could also putrename
on a single field. The top levelrename
would then simply set the default for enum items.JelteF commentedon Nov 21, 2022
A good question raised in the thread in #225 would be what should be the default? My summary of that discussion is that there are two different usages for which a different default makes sense:
I'd say go for strict by default for now, i.e. error by default. Then if that is deemed too cumbersome we can always relax the default. However, unrelaxing the default would be a breaking change.
ilslv commentedon Nov 22, 2022
@JelteF
Actually
#[display(rename("..."))
is an alias for direct#[display("...")]
, so I would vote forrename_all
as seen inserde
and already widespread across the ecosystem.I think that going explicitly over implicitly is a viable option, but only when it's consistent. We already have 2 examples for implicit display:
I see implicit
Display
impl on enums with unit fields as understandable and discoverable continuation for that:Moreover this behaviour is already usable on
master
(and released as well):affix
is confusing with outer-levelenum
display formatting #142marcocondrache commentedon Dec 30, 2023
Any update on this issue? Applying a pre processing function on every variant name is very useful in different situations.
JelteF commentedon Jan 3, 2024
Okay this dropped off my radar.
@marcocondrache at the moment we're focussing on tasks that are blockers of 1.0.0, this is not one of them, because it can be implemented in a backwards compatible way. Feel free to contribute a PR that implements this.
@ilslv Sorry I didn't respond. Your response make total sense. Let's go with
rename_all
and implicitely doing it (because we already do that and it doesn't seem worth breaking backwards compatibility for this).