1.12.1 [2018.01.11]

1.12 [2017.12.07]

Adapt to the EmptyDataDeriving proposal (introduced in GHC 8.4):

Generics.Deriving.TH now derives to(1) and from(1) implementations
for empty data types that are strict in the argument.

Introduce an EmptyCaseOptions field to Options in
Generics.Deriving.TH, which controls whether generated from(1)/to(1)
implementations for empty data types should use the EmptyCase extension
or not (as is the case in GHC 8.4).

Add mkFrom0Options, mkFrom1Options, mkTo0Options, and mkTo1Options
functions to Generics.Deriving.TH, which take EmptyCaseOptions as
arguments.

The backported instances for V1 are now maximally lazy, as per
EmptyDataDeriving. (Previously, some instances would unnecessarily force
their argument, such as the Eq and Ord instances.)

1.11.1 [2016.09.10]

1.11

The behavior of functions in Generics.Deriving.TH have changed with respect
to when type synonyms are generated for Rep(1) definitions. In particular:

By default, deriveRepresentable(1) will no longer define its Rep(1)
type family instance in terms of the type synonym that has to be generated
with deriveRep(1). Similarly, deriveAll(1) and deriveAll0And1 will no
longer generate a type synonym. Instead, they will generate Generic(1)
instances that directly define the Rep(1) instance inline. If you wish
to revert to the old behavior, you will need to use the variants of those
functions suffixed with -Options.

New functions makeRep0Inline and makeRep1Inline have been added which,
for most purposes, should replace uses of makeRep0/makeRep0FromType
and makeRep1/makeRep1FromType (but see the next bullet point for a
caveat).

The use of deriveRep(1), makeRep0/makeRep0FromType, and
makeRep1/makeRep1FromType are now discouraged, but those functions are
still available. The reason is that on GHC 7.0/7.2/7.4, it is impossible to use
makeRep0Inline/makeRep1Inline due to a GHC bug. Therefore, you must use
makeRep0/makeRep1 and deriveRep(1) on GHC 7.0/7.2/7.4 out of necessity.

These changes make dealing with Generic instances that involve PolyKinds
and TypeInType much easier.

All functions suffixed in -WithKindSigs in Generics.Deriving.TH have been
removed in favor of a more sensible -Options suffixing scheme. The ability to
toggle whether explicit kind signatures are used on type variable binders has
been folded into KindSigOptions, which is an explicit argument to
deriveRep0Options/deriveRep1Options and also a field in the more general
‘Options’ data type.

Furthermore, the behavior of derived instances’ kind signatures has changed.
By default, the TH code will now always use explicit kind signatures
whenever possible, regardless of whether you’re working with plain data types
or data family instances. This makes working with TypeInType less
surprising, but at the cost of making it slightly more awkward to work with
derived Generic1 instances that constrain kinds to * by means of (:.:).

Since Generic1 is polykinded on GHC 8.2 and later, the functions in
Generics.Deriving.TH will no longer unify the kind of the last type
parameter to be *.

Fix a bug in which makeRep (and similarly named functions) would not check
whether the argument type can actually have a well kinded Generic(1)
instance.

1.10.0

On GHC 8.0 and up, Generics.Deriving.TH uses the new type literal-based
machinery

Rewrote the Template Haskell code to be robust. Among other things, this fixes
a bug with deriving Generic1 instances on GHC 7.8, and makes it easier to
derive Generic1 instances for datatypes that utilize GHC 8.0’s -XTypeInType
extension.

Added deriveAll0 and makeRep0 for symmetry with deriveAll1 and
makeRep1

AddedmakeRep0FromType and makeRep1FromType to make it easier to pass
in the type instance (instead of having to pass each individual type
variable, which can be error-prone)

Added functions with the suffix -WithKindSigs to allow generating type
synonyms with explicit kind signatures in the presence of kind-polymorphic
type variables. This is necessary for some datatypes that use
-XTypeInType to have derived Generic(1) instances, but is not turned on
by default since the TH kind inference is not perfect and would cause
otherwise valid code to be rejected. Use only if you know what you are doing.

Fixed bug where a datatype with a single, nullary constructor would generate
incorrect Generic instances