Allow the use of `deriving` for GHC generics
|Reported by:||kosmikus||Owned by:||dreixel|
|Keywords:||Generics||Cc:||leather@…, hvr@…, v.dijk.bas@…, cgaebel@…, pho@…, carter.schonwald@…, gregmainland@…|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||#5462||Differential Rev(s):|
Description (last modified by )
Currently, a class that makes use of generic default methods (via the
DefaultSignatures) extension can be instantiated by providing an empty instance declaration.
I propose to allow the use of
deriving as well:
- Standalone deriving should be usable for a class not only for the specific set of classes supported by GHC now, but in addition for any class, if (
- there's at least one generic default given for a method of the class, and
- there are generic or normal default implementations for *all* methods of the class.
There are a number of advantages of this solution over the empty instance declaration: we make it explicit that something generic is going on here; we ensure at compile time that we're not missing an implementation of a method; and we come syntactically closer to built-in derivable classes.
In cases where a conflict arises between current GHC semantics and the proposed semantics (for example, when newtype-deriving is involved, I guess), I propose to stick with current GHC semantics, but I'm open for other suggestions.
- I'd also like for normal
derivingto be useful under the same conditions as above. For normal
derivingGHC has to figure out the class context automatically. I propose that if normal
derivingis used, GHC uses the same heuristic for figuring out the class context that it uses for
Eqin the case of
*-kinded classes, and for
Functorin the case of
* -> *-kinded classes. That may not be optimal or even wrong. But in such cases, standalone deriving can still be used.
Change History (12)
comment:3 Changed 4 years ago by
comment:11 Changed 3 years ago by
|Related Tickets:||→ #5462|
|Status:||new → closed|