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

Contributor advice on the use of non_exhaustive enums #8044

Open
james7132 opened this issue Mar 11, 2023 · 0 comments
Open

Contributor advice on the use of non_exhaustive enums #8044

james7132 opened this issue Mar 11, 2023 · 0 comments
Labels
A-Meta About the project itself C-Code-Quality A section of code that is hard to understand or change

Comments

@james7132
Copy link
Member

james7132 commented Mar 11, 2023

What problem does this solve or what need does it fill?

Any addition of a variant to a public enum is a semver incompatible breaking change, as seen in #8042. If we're looking to make patch releases a regular thing, and as the engine heads towards stability, a common policy on the use of the non_exhaustive attribute on public enums should be in place.

What solution would you like?

Set up a common policy of some kind. Document it well. Enforce it during code review.

What alternative(s) have you considered?

Leave all of our enums as is, let changes be breaking.

Additional context

https://doc.rust-lang.org/reference/attributes/type_system.html

@james7132 james7132 added C-Code-Quality A section of code that is hard to understand or change A-Meta About the project itself labels Mar 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Meta About the project itself C-Code-Quality A section of code that is hard to understand or change
Projects
None yet
Development

No branches or pull requests

1 participant