You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For NoUninit, if the struct itself is #[repr(packed)] with align 1 and the generic is also NoUninit, I believe it should be safe to derive since there shouldn't be any padding bytes and the rest of the checks should run for the the remaining fields in the derive macro. I would be happy to add this change if I'm not overlooking something.
As for CheckedBitPattern, I'm not entirely sure if there is some specific reason why generics aren't supported. From my understanding there's nothing in the trait that inherently prevents something like this. I would be happy to attempt a macro change for this as well.
The text was updated successfully, but these errors were encountered:
For
NoUninit
, if the struct itself is#[repr(packed)]
with align 1 and the generic is alsoNoUninit
, I believe it should be safe to derive since there shouldn't be any padding bytes and the rest of the checks should run for the the remaining fields in the derive macro. I would be happy to add this change if I'm not overlooking something.As for
CheckedBitPattern
, I'm not entirely sure if there is some specific reason why generics aren't supported. From my understanding there's nothing in the trait that inherently prevents something like this. I would be happy to attempt a macro change for this as well.The text was updated successfully, but these errors were encountered: