<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods <br>
and -Wmissing-fields warnings into errors by default (retaining the <br>
option to downgrade them)
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I'm fine with making these errors, provided the impact on library authors is not too severe. But this is a breaking change and people will shout at us. <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><b><br></b></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><b>Moritz</b>, on the face of it this is just the kind of thing you dislike -- and yet it makes it much harder to inadvertently create truly nasty bugs.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">This doesn't affect the API of base, and so is no in CLC purview, but I'd quite like to ask their opinion. What I don't want is for us to accept it, and then have a firestorm of complaints. I think the case is strong: debugging infinite loops is very painful.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:tahoma,sans-serif" class="gmail_default">
The proposal establishes the precedent that some warnings may be treated <br>
as errors by default</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">This is a funny thing. A warning that is an error by default is perhaps.. an error? Or to put it another way, perhaps all errors are just warnings that are treated as errors by default?</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Perhaps this new beast is an error that can be turned into a warning? (Most errors cannot.)</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I'm not arguing against the proposal, just wondering if there is a simpler way to say this.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Sept 2023 at 09:33, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Committee,<br>
<br>
Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods <br>
and -Wmissing-fields warnings into errors by default (retaining the <br>
option to downgrade them). I recommend we accept the proposal.<br>
<br>
Proposal: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a><br>
Rendered: <br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a><br>
<br>
This is primarily motivated by the fact that when classes have default <br>
methods, missing methods can lead to runtime loops, which are generally <br>
difficult to debug. Since in practice not all users pay attention to <br>
warnings that do not inhibit compilation, it makes sense to identify a <br>
class of warnings that are sufficiently serious to require explicit <br>
action from the user to silence them.<br>
<br>
Since these warnings are currently not errors by default, library <br>
authors experimentally assessing the impact of changes may be lead to <br>
assume that introducing new methods/fields does not lead to breakage <br>
(because downstream code will still compile). The proposal thus makes it <br>
more obvious that adding a new method or field is a breaking change.<br>
<br>
The proposal deliberately causes builds to fail by default for some <br>
libraries that currently emit warnings. Oleg has kindly performed impact <br>
assessments to identify such libraries, and the breakage of a few <br>
packages seems worth the cost.<br>
<br>
It is easy to restore the warnings to their previous classification by <br>
passing an option at build time, e.g. using -Wno-error=missing-methods. <br>
Users can set such an option in cabal.project or stack.yaml to work <br>
around breakage that is not promptly fixed by the library author.<br>
<br>
This change does mean that GHC with -XHaskell98/2010 will by default <br>
reject some programs that are explicitly permitted by the Haskell98/2010 <br>
specification. I recommend we document this infelicity, but accept it, <br>
as much of the benefit of the proposal is that it applies by default.<br>
<br>
The proposal establishes the precedent that some warnings may be treated <br>
as errors by default, and introduces a warning group -Wsevere to <br>
classify them. This seems conceptually useful and gives us the option to <br>
extend the -Wsevere set in the future (e.g. as a final stage of <br>
deprecation before a feature is removed).<br>
<br>
Thoughts?<br>
<br>
Adam<br>
<br>
<br>
On 11/09/2023 20:25, Joachim Breitner wrote:<br>
> Dear Committee,<br>
> <br>
> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a<br>
> warning group -Wsevere for on-by-defaults, error-by-default warnings,<br>
> and initially fill it with missing-methods and missing-fields.<br>
> <br>
> <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a><br>
> <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a><br>
> <br>
> I’d like to nominate Adam as the shepherd, who already reviewed it a<br>
> bit on Github.<br>
> <br>
> Please guide us to a conclusion as outlined in<br>
> <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
> <br>
> <br>
> Cheers,<br>
> Joachim<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>