`TypeError` thrown in standalone `via` deriving but not attached `via` deriving
Summary
A newtype
for via
deriving is provided that gives a TypeError
, effectively banning the instance from use, but with a nice error message. We use this at work to prevent folks from running database operations in the "main" monad, and instead guide them towards runDB
which handles transactions.
Steps to reproduce
{-# language DerivingVia #-}
{-# language DataKinds #-}
{-# language UndecidableInstances #-}
{-# language StandaloneDeriving #-}
module Woops where
import GHC.TypeLits
class C a where
f :: a -> a
newtype Can'tBeC a = Can'tBeC a
instance ( TypeError ('Text "No")) => C (Can'tBeC a) where
f = error "unreachable"
instance C Int where f = id
data Good = Good
deriving C via (Can'tBeC Good)
data Bad = Bad
deriving via Can'tBeC Bad instance C Bad
With GHC 9.6.1, I get the following result:
λ ~/Projects/ghc-woops/ master* cabal build
Build profile: -w ghc-9.6.1 -O1
In order, the following will be built (use -v for more details):
- ghc-woops-0.1.0.0 (lib) (file src/Woops.hs changed)
Preprocessing library for ghc-woops-0.1.0.0..
Building library for ghc-woops-0.1.0.0..
[2 of 2] Compiling Woops ( src/Woops.hs, /home/matt/Projects/ghc-woops/dist-newstyle/build/x86_64-linux/ghc-9.6.1/ghc-woops-0.1.0.0/build/Woops.o, /
home/matt/Projects/ghc-woops/dist-newstyle/build/x86_64-linux/ghc-9.6.1/ghc-woops-0.1.0.0/build/Woops.dyn_o ) [Source file changed]
src/Woops.hs:25:1: error: [GHC-64725]
• No
• In the third argument of ‘ghc-prim-0.10.0:GHC.Prim.coerce’, namely
‘(f @(Can'tBeC Bad))’
In the expression:
ghc-prim-0.10.0:GHC.Prim.coerce
@(Can'tBeC Bad -> Can'tBeC Bad) @(Bad -> Bad) (f @(Can'tBeC Bad))
In an equation for ‘f’:
f = ghc-prim-0.10.0:GHC.Prim.coerce
@(Can'tBeC Bad -> Can'tBeC Bad) @(Bad -> Bad) (f @(Can'tBeC Bad))
When typechecking the code for ‘f’
in a derived instance for ‘C Bad’:
To see the code I am typechecking, use -ddump-deriv
|
25 | deriving via Can'tBeC Bad instance C Bad
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is consistent going back to GHC 8.10.7.
Expected behavior
I expect that the StandaloneDeriving
and attached deriving have the same behavior.
But, to be totally specific, I do want both instances to be accepted. The purpose of providing the TypeError
instance here is to provide helpful error messages to folks that are using these, so instead of seeing No instance for C Bad
they see You need to do X if you want to use C in the Bad type
or similar.
Environment
- GHC version used: 9.6.1, 9.4.5, 9.2.7, 8.10.7
Optional:
- Operating System: Ubuntu
- System Architecture: x86