#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