Storable instance of () is broken

David Feuer david.feuer at
Wed Jan 5 08:13:46 UTC 2022

I don't think it's broken; I think your length calculation is broken.
Instead of asking every use of () to take an extra byte, why don't you just
store a word saying how long your array is?

Alternatively, you could probably avoid special cases with a newtype:

newtype NZS a = NZS { unNZS :: a }

instance Storable a => Storable (NZS a) where
    | sizeof (undefined @a) == 0
    = const 1
    | otherwise = sizeof .# unNZS
  alignment = alignment .# unNZS
  peekElemOff = coerce (peekElemOff @a)

On Wed, Jan 5, 2022, 3:01 AM Harendra Kumar <harendra.kumar at>

> The Storable instance of () is defined in the "Foreign.Storable"
> module of the "base" package as follows:
> instance Storable () where
>   sizeOf _ = 0
>   alignment _ = 1
>   peek _ = return ()
>   poke _ _ = return ()
> The size of () is defined as 0. It sounds absurd for a Storable to
> have a size of 0? This means that we can read an infinite number of ()
> type values out of nothing (no memory location required) or store an
> infinite number of () type values without even requiring a memory
> location to write to.
> This is causing a practical problem in our Storable array
> implementation. The array is constrained to a Storable type. Since ()
> has a Storable instance, one can store () in the Storable array. But
> it causes a problem because we determine the array element size using
> sizeOf on the type. For () type it turns out to be 0. Essentially, the
> array of () would always be of size 0. Now, we cannot determine the
> length of the array from its byte length as you could store infinite
> such elements in an empty array. The Storable instance of () seems to
> be an oddity and makes us use a special case everywhere in the code to
> handle this, and this special casing makes it highly prone to errors
> when we change code.
> Can this be fixed? Is there a compelling argument to keep it like
> this? A possible fix could be to represent it by a single byte in
> memory which can be discarded when reading or writing. Another
> alternative is to not provide a Storable instance for it at all. Let
> the users write their own if they need it.
> If you think this does not have a problem, can you suggest how to
> elegantly handle the array implementation problem as I described
> above?
> Thanks,
> Harendra
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list