<div dir="ltr">I'm inclined to follow Adam and make -Werror=severe the default immediately. But I don't feel strongly about it.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Sept 2023 at 20:41, 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>
It seems we are somewhat split on the -Wsevere proposal, even assuming <br>
it is introduced with a deprecation period (changing the warning text <br>
and adding the group in advance). There is consensus that adding the <br>
group by itself is fine, and potentially enabling -Werror=severe under <br>
GHC2024, but enabling it by default for existing code is more controversial.<br>
<br>
Ultimately this is a judgement call about the value of the proposal <br>
versus the breakage it causes. I remain of the view that it is <br>
worthwhile. This is not merely about more aggressively enforcing best <br>
practice. Rather, it eliminates the risk of the following:<br>
<br>
* Suppose package A defines a type class, package B depends on package <br>
A, and package C depends on package B.<br>
<br>
* Now package A extends the type class definition with a new method and <br>
default methods. Everything still compiles; package B now issues a <br>
-Wmissing-methods warning (but is not actively maintained, and the <br>
author of package C is unlikely to look at warnings in all their <br>
dependencies).<br>
<br>
* Users of package C have to try to debug an infinite loop.<br>
<br>
Given that this change avoids a significant issue, affected code has <br>
been issuing warnings for many years, and impacted users can very easily <br>
set -Wwarn=severe either at the package level or the project level, I <br>
think is worth accepting the backwards compatibility cost and the fact <br>
that some Haskell2010 code will no longer be accepted by default.<br>
<br>
Matt Parsons puts it well in the CLC thread, which is pretty clearly in <br>
favour of this proposal overall <br>
(<a href="https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889" rel="noreferrer" target="_blank">https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889</a>):<br>
<br>
 > I think GHC should strive to make fewer breaking changes, and make <br>
those changes as easy-to-adopt as possible. But this is not a question <br>
of GHC breaking things, but rather revealing and providing <br>
early-diagnosis for already broken things.<br>
<br>
Further opinions are welcome, of course.<br>
<br>
Adam<br>
<br>
<br>
On 14/09/2023 09:32, Adam Gundry wrote:<br>
> 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 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>