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

Document why we don't require a repr for an enum to be FromZeroes #146

Open
joshlf opened this issue Nov 15, 2022 · 0 comments
Open

Document why we don't require a repr for an enum to be FromZeroes #146

joshlf opened this issue Nov 15, 2022 · 0 comments
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking

Comments

@joshlf
Copy link
Member

joshlf commented Nov 15, 2022

When deriving FromZeroes on an enum, and in the safety requirements in the doc comment for that trait, we don't require the enum to have an explicit repr attribute. The justification is that, regardless of repr, an enum's discriminant is well-defined according to the reference. We should document this justification in the FromZeroes docs like we do for not requiring a repr for that trait (or for FromBytes).

Is this actually sound?

Though I was initially convinced by this argument, I'm now second-guessing myself since, even if the discriminant's semantic value is well-defined without an explicit repr, it's less clear that the layout of an enum (ie, how its bits are used to represent that semantic value) is well-defined.

If it turns out that this is actually unsound, then of course we should change the behavior before releasing rather than documenting a justification for it.

cc @djkoloski

@joshlf joshlf added the blocking-next-release This issue should be resolved before we release on crates.io label Nov 15, 2022
@joshlf joshlf changed the title Are we too permissive when deriving FromZeroes on enums? Document why we don't require a repr for an enum to be FromZeroes Nov 15, 2022
@joshlf joshlf added the compatibility-nonbreaking Changes that are (likely to be) non-breaking label Aug 12, 2023
@joshlf joshlf mentioned this issue Aug 20, 2023
@joshlf joshlf removed the blocking-next-release This issue should be resolved before we release on crates.io label Sep 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking
Projects
None yet
Development

No branches or pull requests

1 participant