[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:  patch
        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):  Phab:D2280
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:46 oerjan]:
 > * I ''really'' don't think `Enum` belongs in 2(b), which is why I put a
 question mark on it in the first place. I think it should also be moved to
 the bottom left cell in the table.

 I don't follow. Why should it be in the "never" category? As noted above,
 there are scenarios when GHC will derive `Enum` for newtypes, and they are
 perfectly captured in 2(b).

 > * Even though it's explained below, I have a hunch the phrase "bespoke
 typeclass instance" could be misinterpreted as referring to the selected
 strategy. It's a little longer, but "instance for a bespoke typeclass"
 feels less ambiguous.

 This is why I hate choosing syntax :)

 I'm going strictly by the dictionary definition of "bespoke" here, which
 means "tailor-made" or "custom-fit". That means the phrase "bespoke
 typeclass" doesn't make sense, since "bespoke" is a property of the
 instance, not the typeclass.

 > * The paragraph starting "Step 2.(b) deserves some explanation." doesn't
 make sense with the new algorithm, since the issue no longer applies with
 the new control flow. (After all, one of the things simplifying it is that
 step 2 doesn't need to consider anyclass any more, and step 3 doesn't need
 to consider bespoke.)

 I've reworded it to make it a little clearer, hopefully.

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