Closed identicalsnowflake closed 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.
Is there a reason for the
Identity
instance to beStorable a => Store (Identity a)
instead ofStore 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 aStorable
constraint likeStorable a => Storable (Vector a)
andStorable 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!