<div dir="auto">I think the git pull request cycle provides a great deadline for warnings. Well-run projects typically expect code to be -Wall clean before being merged. That sort of discipline is good for personal projects too—everything should be clean before merging a feature branch to the main one.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 21, 2020, 6:04 PM Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:<br>
<br>
> [0] <a href="https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3" rel="noreferrer noreferrer" target="_blank">https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3</a><br>
<br>
He's pretty right about pattern matching and -Wall and <br>
-Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the <br>
two latter ones are not part of -Wall. But this is not your proposal.<br>
<br>
I have always -Wall on, especially during early development. I can ignore <br>
warnings. But I will always remove the cause for warnings before making a <br>
commit. Warnings remind me on the unfinished bits. Thus also warnings <br>
about unused imports, unused parameters, unused functions are very <br>
important for me.<br>
<br>
I would even like to see some warnings before or along type errors. <br>
Currently warnings are shown only after the type errors are resolved. <br>
However, sometimes I get very complicated type errors but actually the <br>
warning "variable x unused" (and thus type inference could not take place) <br>
would be much more helpful.<br>
<br>
I have also taught programming to students. They often like to first run <br>
and test their programs and then resolve warnings somewhen in the future <br>
(or not at all). They are surprised why their programs don't work, whereas <br>
the warnings would directly point them to the problems. But -Wall is <br>
disabled by default. And thus making code warning free looks like an <br>
optional extra.<br>
<br>
On the other hand I do not know how GHC with -Wall as default affects the <br>
tons of packages that are already released.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>