## Summary It's been a recurring theme: Someone looks at GHC, sees the large number of derived instances and thinks: "It would be great to just derive them". However in practice often this comes with a non-trivial compile time cost. This doesn't mean we shouldn't use derived instances at all, but we should document that existing instances should *not* be replaced with derived ones unless there are strong reasons to do so. For a recent example I looked at a shake profile of GHC today and saw that `_build/stage0/compiler/build/GHC/CmmToLlvm/CodeGen.o` took ~40s to build. Which seemed insanely long for what it is and it never stood out during builds to me. So I checked and the culprit was https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15521 which replace some existing manual instances with derived ones. While the idea wasn't bad in practice it made compile time for this module go from 4-5s to \~45s on my machine. That seems not worth it, even less so when the instances already exist. I feel for some projects that is an acceptable overhead. But the GHC code base on average is compiled dozens if not hundred of times in CI and by contributors so optimizing for build time to some degree seems the right thing to do. ## The plan With a heavy heart I plan to revert https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15521 and update the working conventions to explain why we are generally okay with hand written instances and why contributors should not replace existing ones unless there is a strong reason to do so. ## Environment * GHC version used: Optional: * Operating System: * System Architecture: