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

Visibility for EnumIter #237

Open
mdaverde opened this issue Sep 8, 2022 · 3 comments
Open

Visibility for EnumIter #237

mdaverde opened this issue Sep 8, 2022 · 3 comments

Comments

@mdaverde
Copy link

mdaverde commented Sep 8, 2022

It seems currently the struct generated from #[derive(EnumIter)] propagates the visibility from the original enum. Is it possible to have this configurable?

This was mentioned in an early comment and it seems like we have precedent for this in other macros.

A work around I've been using is wrapping my enum in an mod inner { ... } and re-exporting what I want to be public with pub use inner::MyEnum

@Peternator7
Copy link
Owner

Peternator7 commented Sep 19, 2022

I think this triggers a warning/error if you do this? Are you suggesting something like this (playground link)?

Unlike EnumDiscriminants, IntoEnumIterator implements a trait on your enum type which means the iterator type needs to be at least as visible as the Enum type itself.

@mdaverde
Copy link
Author

Okay yeah, I do get an error when I'm missing the same visibility as the enum type.

I tried to experiment with having IntoEnumIterator::iter return an opaque type (e.g. fn iter() -> impl Iterator<Item = Enum>) to further hide the generated EnumIter but that's not currently possible in trait definitions.

I guess we can technically force privacy and get rid of the error by redeclaring an entirely new trait within the module (playground link), but this starts becoming an unfortunate workaround

@Peternator7
Copy link
Owner

It unfortunately does get increasingly awkward to work around. While I think more flexibility is nice, I don't think rust really has the features we need to implement this properly at the moment (not to mention the back-compact difficulties) so I'm going to suggest we hold off making any changes, but I do appreciate the discussion.

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

No branches or pull requests

2 participants