search

mgsloan / store

Fast binary serialization in Haskell
MIT License
109 stars 35 forks source link

Odd constraint on Identity instance #143

Closed identicalsnowflake closed 4 years ago

identicalsnowflake commented 5 years ago

Is there a reason for the Identity instance to be Storable a => Store (Identity a) instead of Store a => Store (Identity a)? The latter seems more sensible to me, not to mention more consistent with the most of the other instances - and the few instances that do have a Storable constraint like Storable a => Storable (Vector a) and Storable a => Storable (Complex a) seem equally as questionable.

I noticed this because I wanted to generalize some of my records to rank 2 versions, and I expected simply dropping in a type alias with the Identity functor plugged in would allow everything to compile as before. To my surprise, it does not!

mgsloan commented 4 years ago

Oops, yeah that's not good, thanks for reporting this issue. I've fixed this and included the fix in version 0.7.0

I suppose this is the downside of code generating Store instances directly from the set of Storable instances. I've updated the logic to not create instances of Storable where Storable appears in the superclass constraints. Seems to be a decent heuristic.

The Storable a => Store (Vector a) instance is actually fine, because in that case it's Data.Vector.Storable.Vector. The instance for that directly copies the vector's byte representation.