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.
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.