It might be a good idea to instead make it so each property carries its own type based on the syntax used to declare it (e.g. int properties declared as foo = 42 as opposed to foo = "42"). That way there could be compile-time checks and there would be lesser risk of typos or of calling get_int on a string property.

Hey @marxin, thanks for the PR! This has been requested for quite a while. I tend to agree with @pali6 though that this would probably be better if accepted literals of the expected type rather than parsing the string.

In some ideal world, we could accept an expression #[strum(props(my_prop = true || false))] but that's difficult because we'd need to figure out the type. I think a better solution in the first version is to change the grammar so that Prop parses a Lit rather than a LitStr then we can do a pattern match in the macro to figure out what type of property we're looking at.

Here we go. I've implemented the suggested approach for the two functions. Eventually, I decided to track the 3 categories using HashMap in enum_properties_inner, but using arrays (the original commit in this PR) might be possible. Which approach do you prefer?

Looks great to me! thanks for taking the time to work on this :)

Thanks for merging. May I ask you whether you plan to choke a new release any time soon?

bump - @Peternator7 any plans for a new release soon?

@Milo123459 You might've seen already but 0.27 has this change