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.

Sign up for GitHub

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

Jump to bottom

Use #[non_exhaustive] for generated enums/flags #884

Closed
sdroege opened this issue Dec 19, 2019 · 3 comments · Fixed by #897
Closed

Use #[non_exhaustive] for generated enums/flags #884

sdroege opened this issue Dec 19, 2019 · 3 comments · Fixed by #897

Comments

@sdroege
Copy link
Member

sdroege commented Dec 19, 2019

Stable since 1.40.
@EPashkin
Copy link
Member

This not applicable for enums, as it already has __Unknown,
also not sure that it applicable to flags in general too.

@sdroege
Copy link
Member Author

sdroege commented Mar 3, 2020

It's still non-exhaustive because we might add other variants at any point, and then the __Unknown variant would not match those cases anymore.

@EPashkin
Copy link
Member

EPashkin commented Mar 4, 2020

Hm, you right, @sdroege

@sdroege sdroege mentioned this issue Apr 10, 2020
Closed
40 tasks
gdesmott pushed a commit to gdesmott/gir that referenced this issue Apr 10, 2020
use #[non_exhaustive] for generated enums
6fa2e64 
Fix gtk-rs#884
@gdesmott gdesmott mentioned this issue Apr 10, 2020
Merged
gdesmott pushed a commit to gdesmott/gir that referenced this issue Apr 10, 2020
use #[non_exhaustive] for generated enums
0df21fe 
Since Rust 1.40 we can use the non_exhaustive attribute to indicate that
more variants may be added in the future.

Adding variants to a C enum is not an API break so it makes sense to
mark all the generated enum as non exhaustive.

Fix gtk-rs#884
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

use #[non_exhaustive] for generated enums gdesmott/gir
2 participants
@sdroege @EPashkin