Feedback on -Wredundant-constraints

Adam Foltzer acfoltzer at
Fri Jun 3 21:33:51 UTC 2016

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list