`derive(Pod)` should work with generic `#[repr(transparent)]` types

[a1phyr]

#[repr(transparent)] guaranties that the type has the same layout that the inner one, so I think that the following examples should work :

#[repr(tansparent)]
#[derive(Zeroable, Pod)]
struct TypedUsize<T>(usize, PhantomData<T>);

#[repr(transparent)]
#[derive(Zeroable, Pod)] // with `T: Pod` or `T: Zeroable` bound
struct Unsync<T>(T, PhantomData<*const ()>);

[Lokathor]

While I'd agree that both of these could have a Pod impl (where T:Pod), I'm not so confident that generically that's always true.

but then again that can maybe be said of some C structs. hmm.

[a1phyr]

I'm not so confident that generically that's always true.

#[repr(transparent)] totally guaranties that if it is.

For #[repr(C)] structs it would be much harder to do I think, this is why my suggestion is to do that for #[repr(transparent)] types only, at least at first.

[Lokathor]

Hm, I suppose if all of the ZST values in the type are also Pod then that would work out correctly. So I think we could do this if that check was part of the derive. Even if it's overly conservative, that's better than being too permissive with an unsafe trait, and people can always bypass the derive's logic and just impl the trait themselves if they are that confident they know the situation best.

As with other derive changes, I don't know that code as well and so I'm very unlikely to make the change myself. However, I could accept a PR for it.