Agreed.  Ive hit exactly these issues myself to the point where i err on suppressing that warning in my code now.  In part because i use those unused constraints as a semantic contract. <span></span><br><br>On Friday, June 3, 2016, Adam Foltzer <<a href="mailto:acfoltzer@gmail.com">acfoltzer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">With 8.0.1 freshly arrived, I'm taking on the task of updating a number of our larger projects here at Galois. I made a couple of these comments briefly on a relevant Trac ticket[1], but I wanted to open this discussion to a wider audience.<div><br></div><div>We tend to use -Wall (and -Werror, in CI environments), and so I've had to make decisions about how to handle the new -Wredundant-constraints warnings. So far, I've come to think of it as two different warnings that happen to be combined:<div><br></div><div>Warning 1: a warning for constraints made redundant by superclass relationships, and</div><div>Warning 2: a warning for unused constraints<div><br></div><div>Overall I'm a fan of Warning 1. It seems very much in the spirit of other warnings such as unused imports. The only stumbling block is how it affects the 3-release compatibility plan with respect to, e.g., the AMP. Most of our code targets a 2-release window, though, so in every such case it has been fine for us to simply remove the offending constraint.</div></div></div><div><br></div><div>Warning 2 on the other hand is far more dubious to me. In the best case, it finds constraints that through oversight or non-local changes are truly no longer necessary in the codebase. This is nice, but the much more common case in our code is that we've made a deliberate decision to include that constraint as part of our API design.</div><div><br></div><div>The most painful example of this I've hit so far is in an API of related functions, where we've put the same constraint on each function even when the implementation of that particular function might not need that constraint. This is good for consistency and forward-looking compatibility (what if we need that constraint in the next version?). The warning's advice in this case makes the API harder to understand, and less abstract (the client shouldn't care or know that f needs Functor, but g doesn't, if both will always be used in a Functor context).</div><div><br></div><div>On another level, Warning 2 is a warning that we could have given a more general type to a definition. We quite rightly don't do this for the non-constraint parts of the type signatures, so why are we doing it for the constraints?</div><div><br></div><div>I'm happy that Warning 1 is now around, but Warning 2 feels much more like an opinionated lint check, and I really wish it wasn't part of -Wall.</div><div><br></div><div>[1]: <a href="https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15</a></div></div>
</blockquote>