Feedback on -Wredundant-constraints

Carter Schonwald carter.schonwald at
Sat Jun 4 13:11:19 UTC 2016

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.

On Friday, June 3, 2016, Adam Foltzer <acfoltzer at> wrote:

> 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.
> 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:
> Warning 1: a warning for constraints made redundant by superclass
> relationships, and
> Warning 2: a warning for unused constraints
> 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.
> 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.
> 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).
> 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?
> 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.
> [1]:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list