Providing a GNFData instance for V1 #1
Conversation
Although V1 is uninhabited, the lack of an instance for V1 prevents GHC from inferring an instance for types such as (U1 :+: V1), which very much is inhabited. I've encountered types like that when creating Generic instances for certain GADTs.
ghost
assigned 
|
Can you provide a simple concrete example for when this applies? |
|
Sure! I've been working with GADTs similar to that example, but much larger, for the past 6 months. They're "multi-sorted compositional datatypes" (c.f.: the compdata package). I spent much of today figuring out how to write Generic instances for them before I generate them with TH -- took three or four tries, but my best answer uses V1. |
This addresses #1 by providing the new `genericRnfV1` function deferring the otherwise resulting compile-time error to run-time, thereby allowing for a conscious choice of whether deriving for `V1` types is acceptable. This also bumps to version 0.1.1.0 and adds a Cabal 1.18 compatible changelog.
|
As I wanted to retain the ability to trigger compile-time errors, I've pursued a slightly different approach; If this works for you, I'd like to upload this to Hackage soon |
|
There's a typo in the error message ("inhabited"->"uninhabited"), but that looks acceptable. Thanks! |
|
Thanks I fixed the typo and released/uploaded |
Although V1 is uninhabited, the lack of an instance for V1 prevents GHC from inferring an instance for types such as (U1 :+: V1), which very much is inhabited. I've encountered types like that when creating Generic instances for certain GADTs.