<div dir="ltr"><div>I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.<br></div><div><br></div><div>This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Sept 2023 at 08:25, 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">I agree with Joachim's position here.<br>
<br>
Having a -Wsevere group at all would be a good start, but the problem <br>
with stopping at "best-practice guidance" rather than changing the <br>
defaults is that it benefits only those who learn about and follow the <br>
guidance. So it remains a footgun for newcomers.<br>
<br>
Regarding migration, given that GHC has issued these warnings by default <br>
for some time, I don't think we need be too shy about upgrading their <br>
severity. We could have -Wcompat imply -Werror=severe, but that <br>
complicates the semantics of warning groups, and will help only those <br>
who use -Wcompat but don't fix warnings that occur with -Wdefault.<br>
<br>
I suppose as Moritz suggests we could introduce and advertise -Wsevere <br>
in 9.10, and mention in the warning message that this will be an error <br>
in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so <br>
9.10 would give something like:<br>
<br>
M.hs:8:10: warning: [-Wmissing-methods]<br>
• No explicit implementation for<br>
‘<>’<br>
• In the instance declaration for ‘Semigroup T’<br>
• Warning: this may lead to an infinite loop or runtime exception.<br>
• This will become an error by default in a future GHC release;<br>
use -Werror=severe to make severe warnings into errors now.<br>
<br>
Then in a future release:<br>
<br>
M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]<br>
• No explicit implementation for<br>
‘<>’<br>
• In the instance declaration for ‘Semigroup T’<br>
• Warning: this may lead to an infinite loop or runtime exception.<br>
• Use -Wwarn=missing-methods to permit this anyway.<br>
<br>
Would that be a reasonable compromise?<br>
<br>
Adam<br>
<br>
<br>
On 19/09/2023 22:13, Joachim Breitner wrote:<br>
> Hi,<br>
> <br>
> Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:<br>
>> Maybe implementing this "severe" category, but not changing its<br>
>> default to error, would get us some of the way there? Then "best-<br>
>> practice guidance" could be "use -Werror=severe", and job done.<br>
>> That's a bit easier to say than saying "use -Werrror=missing-methods<br>
>> -Werror= ..." etc.<br>
> <br>
> anyone using `-Werror` would already get this behavior. So what is the<br>
> useful for using `-Werror=severe` instead? Presumably the rationale is:<br>
> <br>
> -Werror, while great _during_ development or in leaf packages, is not<br>
> is not good idea in _released_ code, i.e. code that is compiled by<br>
> others, as that code needs to keep working even as compilers and<br>
> dependencies change, such as libraries on hackage, or executables<br>
> built by distro packagers.<br>
> That’s why -Werror is frowned upon there.<br>
> <br>
> But some changes in upstream packages _ought_ to cause compilation to<br>
> fail, because they really need downstream code changes. These will<br>
> cause severe warnings, and therefore -Werror=severe is desirable<br>
> even for released code.<br>
> <br>
> Is that a good way of phrasing your thoughts there?<br>
> <br>
> It looks reasonable to me; if we think of deferable type error as<br>
> severe warnings, it totally fits this description: It would be<br>
> _possible_ to keep compiling the downstream code, but it would not be<br>
> desirable. That's why compilation fails, and that’s why we don’t defer<br>
> type errors by default.<br>
> <br>
> But if -Werror=severe is desirable generally, it would be unfortunate<br>
> if we cannot make it the default. If not right away, then maybe with a<br>
> suitable migration strategy? (Although I wonder if there are many users<br>
> out there that pay attention to deprecation warnings, e.g. watch<br>
> -Wdeprecation, that would not have already fixed -Wdefault warnings<br>
> about missing fields/methods already…)<br>
> <br>
> <br>
> Cheers,<br>
> Joachim<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>