Feedback on -Wredundant-constraints

[Carter Schonwald]

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 gmail.com> 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]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160604/c224520d/attachment.html>