#10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): An alternative would be to require an instance declaration for DAD, thus {{{ instance C a => C (T a) }}} That's all that is required, provided `C` has suitable generic default methods and `T` is an instance of `Generic`. And if DAC always used this route, there'd be less ambiguity in the `deriving` clause of a data type declaration. I think (but I am not sure) that we don't allow standalone deriving for DAC; thus {{{ deriving instance C a => C (T a) }}} would not work for DAC. Is that right? It seems reasonable to disallow it, because it's one word longer than the ordinary instance declaration. And if it is disallowed, then builtin and GND are already treated differently to DAC. So we'd get * GND/builtin: `deriving` clauses and `deriving instance` declarations * DAC: always a plain `instance` decl I know that's not backward compatible.. On Ryan's synonym thing, like oerjan I'm uncomfortable with pressing synonyms into service like this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10598#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler