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
#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 oerjan): Replying to [[ticket:10598#comment:47|RyanGlScott]]: they are perfectly captured in 2(b). Oh, I'd missed that. I guess removing the question mark was fine, then. However, that means `Enum` alone ''doesn't'' fit properly into my intended table scheme, since it's sort of a hybrid between lower left and middle right (actually, ''upper'' right, since there's no check needed on the shape of the newtype). Which means the current table indeed only describes when to do GND. Possibly, it could fit in the middle ''left'' if the table is slightly relabeled, so that the rows tell what to do about GND and the columns tell about general use. Like so: |||| ||= No extension required =||||= Requires language extension to use =|| ||= GND when possible =|| 2(a) || `Eq`, `Ord`, `Ix`, `Bounded` |||| || ||= GND with extension =|| 2(b) || `Enum` || 2(b) || `Functor`, `Foldable` || ||= Never select GND =|| 2(c) || `Read`, `Show` || 2(c) || `Data`, `Generic`, `Generic1`, `Typeable`, `Traversable`, `Lift` || Which reminds me, I think maybe the word "silly" in step 1 should be "impossible", since after all some very silly things ''are'' allowed, like using anyclass on a class that doesn't support it.
* 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. Right. (I have no prior relationship with that word myself.) Anyway my point is that at this point in the algorithm, you ''don't'' want to branch on the (not yet) selected instance, but only on the class. This means you might not want to use a syntax ("bespoke typeclass instance") that could imply that "bespoke" is a property of ''that'' instance.
I've reworded it to make it a little clearer, hopefully.
My quibbling mind says that "when it would otherwise derive a `bespoke` instance" should be something like "when it supports `bespoke` instances", otherwise there are still corner cases that aren't obviously caught, such as deriving `Foldable` for a newtype with GND, deriving `Enum` for a newtype, or even (when interpreted intuitively) deriving an instance for which bespoke is selected, but the derivation fails for some other reason. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10598#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler