<div dir="ltr"><div>(I'd argue that most errors can be turned into warnings via -fdefer-type-errors. It's really coarse though.)</div><div><br></div><div>When reading the summary, I was anticipating voting against the proposal, turning warnings into errors by default creates spurious work for package maintainers. But I think I'm now convinced. Joachim & Oleg's point is that we want to consider creating additional `-Wsevere` warnings *to not be backward compatible*. It's an obligation on GHC designers, and on package maintainers: such change must be considered very carefully and must be properly documented. If we break compatibility this way, we want to trigger as many errors as possible, so that packages get fixed (which they almost certainly need to).<br></div><div><br></div><div>This is the criterion for having a warning be part of `-Wsevere`. And the two first contestants (missing methods and missing fields) absolutely seem to fit the bill.</div><div><br></div><div>So I'm in favour.<br></div><div><br></div><div>I have no opinion about whether there is a better way to describe the spectrum of error-to-warning, as per Simon's musing.</div><div><br></div><div>I agree that the CLC should be consulted on this, as it also imposes duties on them.</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Sept 2023 at 11:10, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.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"><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" target="_blank">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>
_______________________________________________<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><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>