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

enum_derive::IterVariantNames trait #32

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

main--
Copy link

@main-- main-- commented Sep 17, 2017

No description provided.

@DanielKeep
Copy link
Owner

So, the problem with this is that it breaks backward compatibility. Everyone who was using this macro will now have to use the trait to get at the generated method.

I'm also unconvinced that this is useful. Under what situations do you need the ability to pass multiple enum types to generic code so that it can iterate over the variant names, but nothing else?

@main--
Copy link
Author

main-- commented Sep 19, 2017

Under what situations do you need the ability to pass multiple enum types to generic code so that it can iterate over the variant names, but nothing else?

Of course, it's not very useful on its own. But combined with EnumDisplay and EnumFromStr you can build a wrapper that can access and modify an enum property as strings generically, without ever knowing the concrete enum type.

Or a little less abstract: I'm experimenting with generic configuration interfaces. To configure enum settings, I need to display the current value, list available options and finally parse it back to the enum type.

I'm not sure what the standard workarounds for this kind of backwards compatibility issue are. I guess you would have both the free function and the trait and one calls the other but I'm not 100% sure so I didn't do it since I didn't need it for my usecase. In other words: Think of this PR as a suggestion, not a polished solution.

DanielKeep added a commit that referenced this pull request Sep 22, 2017
This avoids the issues of the proposed PR by having both the inherent
method *and* the trait, and by using a different method name for the trait.
This is less than ideal, but solves the backwards compatibility issues well
enough.

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

Successfully merging this pull request may close these issues.

2 participants