Storable instances have incorrect alignment

[expipiplus1]

Seems to always be 1!

[mgsloan]

Good point! It should be documented that these instances only work with processors that support unaligned memory access (nearly all, and modern processors have nearly 0 overhead for unaligned access). Leaving this issue open to track the documentation concern.

The alignment value is correct.

[expipiplus1]

One of the primary purposes of Storable instances is in interop with languages such as C which do respect alignment though.

There are are still many platforms where alignment is important (for instance GPU programming).

I think if it's going to stick with 1 then this has to be spelled out very loudly in the documentation, and also that in addition to the alignment of these instances being 1, the alignment of the components types is ignored (against the direction of the Storable documentation for portable code).

[dpwiz]

Wouldn't it be possible to use "deriving via" wrappers with alignment as a phantom argument?

deriving GStorable via Aligned 4 MyStuff

(I know next to nothing about about deriving-via magic.)

[dpwiz]

FTR, it should be possible to reconstruct Haskell record from SPIR-V reflection of its struct (glsl or otherwise) and make an exact Storable instance for it.

[goertzenator]

Member alignment is also not respected. For example, the Storable instance of ...

data MyStruct = MyStruct
  { p1 :: Int32
  , p2 :: Int64
  }

... will not leave padding after p1 to keep p2 aligned.

Please document that this does not create C compatible Storable instances.