Skip to content

Prohibit user-defined Generic and Generic1 instances

User-defined Generic and Generic1 instances are problematic.

They are susceptible to breakage

Some details of the classes may change between GHC versions, and indeed have done so in the past. User-defined instances are likely to break in the face of various such "internal" changes. This is one reason why Data.Sequence, for example, does not have a Generic instance.

They require potentially-expensive consistency checks

GHC cannot assume that every type has at most one Generic and Generic1 instance, so it needs to look for possible alternatives at instance resolution time. According to Simon (and maybe also Simon), this may be partly responsible for the performance regressions seen in D2899.

Downsides

Prohibiting user-defined instances does have some costs. Suppose a type was originally defined concretely, exposing its constructors and a Generic instance. The implementer may decide later to make the type abstract, and export pattern synonyms to retain the same interface. But the Generic instance will either change or disappear. Someone relying on that instance could be in trouble. If the instance disappears, they'll be forced to write code by hand that they didn't need to before. If it changes, their code may change its behavior unexpectedly.

Trac metadata
Trac field Value
Version 8.0.1
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information