<div dir="auto"><div>Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using pre-GHC2021 myself).<div dir="auto"><br></div><div dir="auto">In that case, I'm suggesting that we enable -Werror=severe in the next GHC20xx iteration, and leave GHC2021 etc. unaffected.</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">Simon</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 Oct 2023, 07:56 Adam Gundry, <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/10/2023 22:04, Simon Marlow wrote:<br>
> My concrete suggestion is we EITHER<br>
> <br>
> * Enable -Werror=severe in future GHC20xx versions only, or<br>
> * Enable it by default and in future GHC20xx versions, but not in<br>
> GHC2021, Haskell2010, or Haskell98<br>
<br>
Sorry, I don't quite understand the difference between these options. <br>
What does it mean to enable -Werror=severe by default but not in <br>
GHC2021, given that GHC2021 is the (current) default?<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
> On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones <br>
> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank" rel="noreferrer">simon.peytonjones@gmail.com</a> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank" rel="noreferrer">simon.peytonjones@gmail.com</a>>> wrote:<br>
> <br>
> I must say that I am strongly influenced by the fact that<br>
> <br>
> * Matt Parsons<br>
> * Andrew Lelechenko (bodigrim)<br>
> <br>
> are both not just in favour, but *strongly *in favour. They must<br>
> think of the case as compelling, because they are both usually very<br>
> careful about unnecessary breakage.<br>
> <br>
> if we make -Werror=severe the default, then any new warning<br>
> added to -Wsevere is a new breaking change, and we would have to<br>
> judge it to be compelling enough by GR2<br>
> <br>
> <br>
> Yes indeed. But that's not a bug -- it's a feature.<br>
> <br>
> To be clear I have no strongly held opinion myself. Perhaps we<br>
> should canvas opinion among people using Haskell in production? We<br>
> did so with CLC but we could do so publicly.<br>
> <br>
> Simon<br>
> <br>
> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank" rel="noreferrer">marlowsd@gmail.com</a><br>
> <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank" rel="noreferrer">marlowsd@gmail.com</a>>> wrote:<br>
> <br>
> I don't think this breaking change (namely making -Werror=severe<br>
> the default) meets the bar for "compelling reason" according to<br>
> GR2 of our proposed policy, so I'm voting against. It's<br>
> certainly not a bug or a security hole. Maybe you could argue<br>
> that it's a design flaw in the language, but I'm not all that<br>
> convinced. It's an unforced breaking change in my opinion. If we<br>
> add "makes it more difficult to shoot yourself in the foot" a<br>
> compelling enough reason to break GR1 then I think we've<br>
> weakened it significantly.<br>
> <br>
> Here's another problem: if we make -Werror=severe the default,<br>
> then any new warning added to -Wsevere is a new breaking change,<br>
> and we would have to judge it to be compelling enough by GR2. If<br>
> we don't make -Werror=severe the default, then we're not<br>
> restricted in what we can add to -Wsevere. Probably -Wsevere<br>
> would end up being more useful as a result.<br>
> <br>
> Cheers<br>
> Simon<br>
> <br>
> <br>
> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones<br>
> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank" rel="noreferrer">simon.peytonjones@gmail.com</a><br>
> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank" rel="noreferrer">simon.peytonjones@gmail.com</a>>> wrote:<br>
> <br>
> Here's my summary:<br>
> <br>
> * There is strong (universal, even) support for the<br>
> `severe` category.<br>
> * There is pretty strong support for making severe<br>
> warnings into errors at some point. As Matt puts it<br>
> "this is not a question of GHC breaking things, but<br>
> rather /revealing/ and providing early-diagnosis for<br>
> /already broken/ things".<br>
> * But I think we are moving towards a policy of giving<br>
> users time to adapt via a deprecation cycle, whenever<br>
> that is feasible. And it is feasible here.<br>
> <br>
> So my suggestion would be:<br>
> <br>
> * When implemented, make `-Wwarn=severe` the default, but<br>
> add to each severe warning a deprecation-style message<br>
> saying that it'll become an error in the next iteration.<br>
> * In the next released, make `-Werror=severe` the default.<br>
> * Don't complicate matters by involving GHC2024. That is<br>
> another conversation, and even if we wanted to include<br>
> `-Werorr=severe` in GHC2024, we would *still* want a<br>
> deprecation cycle!<br>
> <br>
> Would that be acceptable?<br>
> <br>
> Simon<br>
> <br>
> On Fri, 29 Sept 2023 at 19:41, Adam Gundry<br>
> <<a href="mailto:adam@well-typed.com" target="_blank" rel="noreferrer">adam@well-typed.com</a> <mailto:<a href="mailto:adam@well-typed.com" target="_blank" rel="noreferrer">adam@well-typed.com</a>>> wrote:<br>
> <br>
> Dear Committee,<br>
> <br>
> It seems we are somewhat split on the -Wsevere proposal,<br>
> even assuming<br>
> it is introduced with a deprecation period (changing the<br>
> warning text<br>
> and adding the group in advance). There is consensus<br>
> that adding the<br>
> group by itself is fine, and potentially enabling<br>
> -Werror=severe under<br>
> GHC2024, but enabling it by default for existing code is<br>
> more controversial.<br>
> <br>
> Ultimately this is a judgement call about the value of<br>
> the proposal<br>
> versus the breakage it causes. I remain of the view that<br>
> it is<br>
> worthwhile. This is not merely about more aggressively<br>
> enforcing best<br>
> practice. Rather, it eliminates the risk of the following:<br>
> <br>
> * Suppose package A defines a type class, package B<br>
> depends on package<br>
> A, and package C depends on package B.<br>
> <br>
> * Now package A extends the type class definition with a<br>
> new method and<br>
> default methods. Everything still compiles; package B<br>
> now issues a<br>
> -Wmissing-methods warning (but is not actively<br>
> maintained, and the<br>
> author of package C is unlikely to look at warnings in<br>
> 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,<br>
> affected code has<br>
> been issuing warnings for many years, and impacted users<br>
> can very easily<br>
> set -Wwarn=severe either at the package level or the<br>
> project level, I<br>
> think is worth accepting the backwards compatibility<br>
> cost and the fact<br>
> that some Haskell2010 code will no longer be accepted by<br>
> default.<br>
> <br>
> Matt Parsons puts it well in the CLC thread, which is<br>
> 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 noreferrer" target="_blank">https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889</a> <<a href="https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889" rel="noreferrer 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<br>
> changes, and make<br>
> those changes as easy-to-adopt as possible. But this is<br>
> 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<br>
> -Wmissing-methods<br>
> > and -Wmissing-fields warnings into errors by default<br>
> (retaining the<br>
> > option to downgrade them). I recommend we accept the<br>
> proposal.<br>
> ><br>
> > Proposal:<br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a><br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a>><br>
> > Rendered:<br>
> ><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer 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<br>
> classes have default<br>
> > methods, missing methods can lead to runtime loops,<br>
> which are generally<br>
> > difficult to debug. Since in practice not all users<br>
> pay attention to<br>
> > warnings that do not inhibit compilation, it makes<br>
> sense to identify a<br>
> > class of warnings that are sufficiently serious to<br>
> require explicit<br>
> > action from the user to silence them.<br>
> ><br>
> > Since these warnings are currently not errors by<br>
> default, library<br>
> > authors experimentally assessing the impact of<br>
> changes may be lead to<br>
> > assume that introducing new methods/fields does not<br>
> lead to breakage<br>
> > (because downstream code will still compile). The<br>
> proposal thus makes it<br>
> > more obvious that adding a new method or field is a<br>
> breaking change.<br>
> ><br>
> > The proposal deliberately causes builds to fail by<br>
> default for some<br>
> > libraries that currently emit warnings. Oleg has<br>
> kindly performed impact<br>
> > assessments to identify such libraries, and the<br>
> breakage of a few<br>
> > packages seems worth the cost.<br>
> ><br>
> > It is easy to restore the warnings to their previous<br>
> classification by<br>
> > passing an option at build time, e.g. using<br>
> -Wno-error=missing-methods.<br>
> > Users can set such an option in cabal.project or<br>
> stack.yaml to work<br>
> > around breakage that is not promptly fixed by the<br>
> library author.<br>
> ><br>
> > This change does mean that GHC with -XHaskell98/2010<br>
> will by default<br>
> > reject some programs that are explicitly permitted by<br>
> the Haskell98/2010<br>
> > specification. I recommend we document this<br>
> infelicity, but accept it,<br>
> > as much of the benefit of the proposal is that it<br>
> applies by default.<br>
> ><br>
> > The proposal establishes the precedent that some<br>
> warnings may be treated<br>
> > as errors by default, and introduces a warning group<br>
> -Wsevere to<br>
> > classify them. This seems conceptually useful and<br>
> gives us the option to<br>
> > extend the -Wsevere set in the future (e.g. as a<br>
> 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<br>
> proposal to introduce a<br>
> >> warning group -Wsevere for on-by-defaults,<br>
> error-by-default warnings,<br>
> >> and initially fill it with missing-methods and<br>
> missing-fields.<br>
> >><br>
> >><br>
> >><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a><br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a>><br>
> >><br>
> >><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer 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<br>
> already reviewed it a<br>
> >> bit on Github.<br>
> >><br>
> >> Please guide us to a conclusion as outlined in<br>
> >><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a> <<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer 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 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>
</blockquote></div></div></div>