[GHC] #10598: DeriveAnyClass and GND don't work well together

[GHC]

#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 oerjan):

 Replying to [comment:25 RyanGlScott]:
 > It's not quite backwards-compatible—we'd also have to make a breaking
 change to `template-haskell` in order to accommodate the presence of these
 new pragmas. The type synonym approach, however, is only backportable to
 GHC 7.6.

 Ah, there's always something. Which reminds me, Haddock might possibly
 want to know about the distinctions, too.

 > > In any case, you should also decide how to annotate a `class`
 definition, which is where I actually suggested a pragma.
 >
 > I'm not sure what you mean. Are talking about annotating when you should
 use `DeriveAnyClass` (`DAC`)? Or something else?

 DAC or GND, both should be possible to specify. Neither is equivalent to
 having no annotation.

 The annotations on the class not only tell what you normally ''should''
 use, but also guide the compiler's selection for a newtype if the deriving
 clause does not itself have an annotation. Also, annotating the class
 removes the possibility of a warning if GHC must choose between DAC and
 GND because a module enables both as language extensions.

 To re-summarize my suggested system, when choosing what mechanism to use
 for deriving a class for a newtype:

 1. Annotations on the deriving clause take top precedence (with the
 exception of some builtin classes at least including, for safety,
 `Typeable`).
 2. Then builtin derivable status of the class.
 3. Then annotations on the class declaration.
 4. Only if none of the above exists are the module's enabled relevant
 language extensions (GND or DAC) used to choose. If both GND and DAC are
 enabled, a warning is given, and DAC is chosen.
 5. No matter what is chosen in the above, the module must have enabled any
 relevant language extensions.

 The guiding principles here being backwards compatibility (2,4), the
 ability to state intended usage at both class declaration and deriving
 sites (1,2,3), and reducing undetected surprises from irrelevant changes
 (4,5).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10598#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler