Does `Pod` have to require `Zeroable`?
repi opened this issue · 2 comments
There probably is a reason or specific history why Pod derives Zeroable, and I may be missing something but couldn't find a motivation in the docs or code.
Logically to me it feels like all zeroable types would be pod types, but all pod types are not necessarily zeroable. Does that make sense?
Been experimenting with a bunch of use cases in our code (also see #84) and while I can see a use for zeroable types, it is (for us at least) very rare and we do have a lot of pod types that due to this requirement also have to derive and be zeroable and expose ::zereod() to the users without it really making much sense to every crate a zeroable implementation of them - so creates some extra noise and potential confusion with this requirement (for us).
If the type is Pod, that means you're allowed to cast [u8; N] into that type, where N is however many bytes that type is.
Supposing that the array contains all 0 values, then you'd have made the zeroed instance of that type.
Thus, while it might not be useful to have a zeroed instance of the type, it must be legal for that instance to exist. If it's not legal, then the type shouldn't be Pod in the first place.
Seems to me that perhaps some confusion is the Zeroable does not require for ::zeroed to make logical sense, but rather just that zeroed cannot cause the type to expose unsafe behavior, which are quite different requirements. Though perhaps @repi already realizes that and I'm missing something, haha. This does mean that having zeroed method exposed when deriving Zeroable is a bit inconvenient if we don't actually want users readily creating the zeroed version. But, the user would have to import the Zeroable trait to access it anyway, so I don't think it's a huge deal.