
I've been pretty comfortable with using -Wall from the beginning, but I see
the point. I think -Wall is still a good reminder to fix unused bindings,
imports etc.
How about having a flag that disables those warnings while in early
development? That would serve as a more explicit WIP marker.
2020年12月10日(木) 11:23 David Feuer
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
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.