You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Without DerivingStrategies, it's reasonable to think that "deriving instance" together defines a standalone deriving statement, but with DerivingStrategies, it seems more intuitive for deriving + the strategy to be one unit, and instance + types being another. This makes the styling look just like a normal instance block.
Current
newtypeFoo=FooIntderivinginstanceShowFooderiving via
(HexInt)
instanceShowFooderivingnewtypeinstanceShowFoo
Desired
newtypeFoo=FooIntderivinginstanceShowFooderivingnewtypeinstanceShowFooderiving via (HexInt)
instanceShowFoo-- if the user explicitly puts it on the next line, perhaps even-- deriving-- via (Hex Int)-- instance Show Foo
Sounds neat, being anticipatorily forward-compatible with ghc-proposals/ghc-proposals#446 could be sufficient reason to change formatting here (multi-line deriving clauses are also usually pretty self-contained), such that this will be a fixed point:
derivingnewtypeinstanceShowFooinstanceReadFooderiving via -- or also change the newline insertion here
(HexInt) -- as suggested in your examplesinstanceShowFooReadFoo
Without
DerivingStrategies
, it's reasonable to think that "deriving instance" together defines a standalone deriving statement, but withDerivingStrategies
, it seems more intuitive forderiving
+ the strategy to be one unit, andinstance
+ types being another. This makes the styling look just like a normalinstance
block.Current
Desired
Environment
Additional context
Related: ghc-proposals/ghc-proposals#446
The text was updated successfully, but these errors were encountered: