#11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These redundant constraint warnings being in -Wall make it seemingly impossible for us to live up to the '3 Release Policy' in many situations. https://prime.haskell.org/wiki/Libraries/3-Release-Policy Consider the AMP: `(Monad m, Functor m)` gets used as a replacement for `Monad m` in many situations for compatibility with code before GHC 7.8, where that wants to call both `fmap` and something from `Monad`, but from 7.10+ that `Functor` is a redundant constraint. We have no backwards- facing 3-release-compatible constraint that someone could use in a type signature without warning to get both `fmap` and `return` that won't trigger this warning. Similarly if we split a class we can't advocate that folks use the subclass until the superclass is widely available or they'll get spammed with warnings. This affects splitting out `Semigroup` from `Monoid`. A similar issue arises with the `MonadFail` proposal as there is a stage around 8.4 where the 3-release-compatible advice would be to incur a `MonadFail` constraint, even when the active desguaring will be through `Monad`. I don't actually have a fix from the libraries side for the fact that with these showing up in -Wall, the 3 release policy doesn't work. Every single proposal the core libraries committee currently has in the works (except for adding `log1p`, `expm1`, etc. to Floating) is affected by this concern. One possible fix is to demote the redundant superclass warnings out of `-Wall`. This would resolve #11369 as well. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11370 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler