Currently it looks like pod/zeroable structs do not support having enum fields in them, is this correct? As the derive macros for Pod and Zeroable doesn't support enums.

Such as:

#[derive(Copy, Clone, Pod, Zeroable)]
#[repr(C)]
struct TestWithEnum {
  a: u16,
  b: u16,
  e: ContiguousEnum,
}

#[repr(u8)]
#[derive(Clone, Copy, Contiguous)]
enum ContiguousEnum {
  A = 0,
  B = 1,
  C = 2,
}

Though enums that use a primitive representation could be considered pod types (even without the Contiguous additional requirement), and if such an enum implements a variant with value 0 it could support implement Zeroable trait as well right?

One can implement the traits manually for an enum:

unsafe impl bytemuck::Pod for ContiguousEnum {}
unsafe impl bytemuck::Zeroable for ContiguousEnum {}

That said, the crate does specify this as a restriction for what it calls a pod type which could rule out enums, but is a pretty big constraint:

The type must allow any bit pattern (eg: no bool or char, which have illegal bit patterns).

Is this intended as the restriction of why enums are not supported also, or has it simply not been implemented yet in the derive macros? So one could do this instead of manual implementation:

#[repr(u8)]
#[derive(Clone, Copy, Pod, Zeroable, Contiguous)]
enum ContiguousEnum {
  A = 0,
  B = 1,
  C = 2,
}

We have a bunch of use cases in native and shader code where we have pod structs (that do have enums in) that we want to use bytemuck on for the additional compile-time verification that they use the right representation and some limitations, but we are just casting between typed slices and byte slices so maybe what we are after is just a more relaxed pod type that could handle enums and also do not require types to be zeroable (#85)