-
Notifications
You must be signed in to change notification settings - Fork 150
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
fix!: use the tuple value for to_string on default #270
Conversation
This is the no breaking changes approach. It could reasonably break changes by just making this the default behavior. Happy to see this as a PoC of the functionality, and ask for feedback on how it should be configured. Some options: // the current implementation in this PR
#[strum(default, default_to_string)]
// perhaps this PR's behavior should just be the default
#[strum(default)]
// perhaps we could pass a to_string with no value (or with "")
#[strum(default, to_string)] Perhaps the default to_string for a default variant should automatically include the data item e.g. I don't really have a good enough feel for what the correct approach should be on this, so happy to take any guidance. |
I'm not 100% sure why the 1.32 breakage on this happens :? |
I was unpleasantly surprised that |
Same - it's not a big deal, but it meant having to work around it for that catchall case. Do you have any thoughts about the ergonomics of the API of this feature? I haven't used strum before and I'm fairly new to rust, so don't know what would is idiomatic here (and it seems like this crate has some pretty high standards for backwards compatible changes, so getting it right is a one time thing). |
Incidentally running |
Hey @joshka, I've been thinking about this, and I think you're right. |
Sounds like a good plan. Just to confirm, when there is no #[strum(default]
Custom(String)
// Custom("lime") should render as "lime" while if there is a #[strum(default, to_string("custom color")]
Custom(String)
// Custom("lime") should render as "custom color" and at least for now there's no way to render something like "custom color: lime" |
The default attribute on a tuple like variant now causes the to_string and display format to use the value of the tuple rather than the name of the variant. E.g. Color::Green("lime").to_string() will equal "lime" not "Green" Fixes: how to round trip Display and EnumString with default="true" Peternator7#86 BREAKING CHANGE This changes how Display and ToString cause the following to renders: ```rust #[strum(default)] Green(String) ``` To maintain the previous behavior (use the variant name): ```rust #[strum(default, to_string("Green"))] Green(String) ```
Updated PR title and body in case you use github to push rather than doing it locally. New commit message: fix!: use the tuple value for to_string on default The default attribute on a tuple like variant now causes the to_string E.g. Color::Green("lime").to_string() will equal "lime" not "Green" Fixes: how to round trip Display and EnumString with default="true" #86 BREAKING CHANGE #[strum(default)]
Green(String) To maintain the previous behavior (use the variant name): #[strum(default, to_string("Green"))]
Green(String) |
I'm not sure why this is failing with 1.32. Any thoughts? |
Just release |
The default attribute on a tuple like variant now causes the to_string
and display format to use the value of the tuple rather than the name
of the variant.
E.g. Color::Green("lime").to_string() will equal "lime" not "Green"
Fixes: how to round trip Display and EnumString with default="true" #86
BREAKING CHANGE
This changes how Display and ToString cause the following to renders:
To maintain the previous behavior (use the variant name):