Yeah, I think you're missing something. -Wall is great for checking code that's supposed to be "production ready", but it makes some pretty annoying noise when you're deep in development. Probably the most annoying in that context are unused binding warnings (yeah, I'm not using it yet because I'm still writing it and/or other helpers), unused variable warnings (yeah, that'll be used in some case I still need to write), and unused imports (yeah, I've temporarily commented out the code that uses Foo, and I'm pretty sure I'll be needing Bar before I'm done). In that setting, I'm much more likely to want -Wincomplete-patterns (what do I still need to write) and maybe -Wname-shadowing (so I won't have to go back and change a bunch of names later) than full -Wall.

On Wed, Dec 9, 2020, 9:06 PM Fumiaki Kinoshita <fumiexcel@gmail.com> wrote:

I mean literally. An article [0] reminded me of the fact that I enable -Wall in 99% of time -- and most packages I use have it enabled too.
It's well known that -Wall doesn't enable all warnings, but a subset of warnings that

* are well accepted by the community
* rarely produce false positives

Well, they look like good reasons to enable the warnings by default. Same goes for -Wcompat, except that it is not as popular as -Wall. Seeing potential problems when compiling code is far less of a pain than leaving breakages unnoticed.

Am I missing some obvious reason not to do this?

[0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.