<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I will mull on the actual proposal (I feel there is a solution somewhere here that we haven't hit yet), but I wanted to respond to Simon M's comment about deferred cost: The migration cycle is more than just a deferment: it's a smearing. That is, if something breaks suddenly, everyone must upgrade in unison: hard. If something breaks slowly, then people can update their projects when they choose during the migration period: much easier. That difference might not affect an enterprise all that much, but I think it has a sizable impact on open-source developers.<div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 21, 2023, at 8:34 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" class="">marlowsd@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Simon<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><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" class="">adam@well-typed.com</a>> wrote:<br class=""></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 class="">
<br class="">
Having a -Wsevere group at all would be a good start, but the problem <br class="">
with stopping at "best-practice guidance" rather than changing the <br class="">
defaults is that it benefits only those who learn about and follow the <br class="">
guidance. So it remains a footgun for newcomers.<br class="">
<br class="">
Regarding migration, given that GHC has issued these warnings by default <br class="">
for some time, I don't think we need be too shy about upgrading their <br class="">
severity. We could have -Wcompat imply -Werror=severe, but that <br class="">
complicates the semantics of warning groups, and will help only those <br class="">
who use -Wcompat but don't fix warnings that occur with -Wdefault.<br class="">
<br class="">
I suppose as Moritz suggests we could introduce and advertise -Wsevere <br class="">
in 9.10, and mention in the warning message that this will be an error <br class="">
in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so <br class="">
9.10 would give something like:<br class="">
<br class="">
M.hs:8:10: warning: [-Wmissing-methods]<br class="">
• No explicit implementation for<br class="">
‘<>’<br class="">
• In the instance declaration for ‘Semigroup T’<br class="">
• Warning: this may lead to an infinite loop or runtime exception.<br class="">
• This will become an error by default in a future GHC release;<br class="">
use -Werror=severe to make severe warnings into errors now.<br class="">
<br class="">
Then in a future release:<br class="">
<br class="">
M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]<br class="">
• No explicit implementation for<br class="">
‘<>’<br class="">
• In the instance declaration for ‘Semigroup T’<br class="">
• Warning: this may lead to an infinite loop or runtime exception.<br class="">
• Use -Wwarn=missing-methods to permit this anyway.<br class="">
<br class="">
Would that be a reasonable compromise?<br class="">
<br class="">
Adam<br class="">
<br class="">
<br class="">
On 19/09/2023 22:13, Joachim Breitner wrote:<br class="">
> Hi,<br class="">
> <br class="">
> Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:<br class="">
>> Maybe implementing this "severe" category, but not changing its<br class="">
>> default to error, would get us some of the way there? Then "best-<br class="">
>> practice guidance" could be "use -Werror=severe", and job done.<br class="">
>> That's a bit easier to say than saying "use -Werrror=missing-methods<br class="">
>> -Werror= ..." etc.<br class="">
> <br class="">
> anyone using `-Werror` would already get this behavior. So what is the<br class="">
> useful for using `-Werror=severe` instead? Presumably the rationale is:<br class="">
> <br class="">
> -Werror, while great _during_ development or in leaf packages, is not<br class="">
> is not good idea in _released_ code, i.e. code that is compiled by<br class="">
> others, as that code needs to keep working even as compilers and<br class="">
> dependencies change, such as libraries on hackage, or executables<br class="">
> built by distro packagers.<br class="">
> That’s why -Werror is frowned upon there.<br class="">
> <br class="">
> But some changes in upstream packages _ought_ to cause compilation to<br class="">
> fail, because they really need downstream code changes. These will<br class="">
> cause severe warnings, and therefore -Werror=severe is desirable<br class="">
> even for released code.<br class="">
> <br class="">
> Is that a good way of phrasing your thoughts there?<br class="">
> <br class="">
> It looks reasonable to me; if we think of deferable type error as<br class="">
> severe warnings, it totally fits this description: It would be<br class="">
> _possible_ to keep compiling the downstream code, but it would not be<br class="">
> desirable. That's why compilation fails, and that’s why we don’t defer<br class="">
> type errors by default.<br class="">
> <br class="">
> But if -Werror=severe is desirable generally, it would be unfortunate<br class="">
> if we cannot make it the default. If not right away, then maybe with a<br class="">
> suitable migration strategy? (Although I wonder if there are many users<br class="">
> out there that pay attention to deprecation warnings, e.g. watch<br class="">
> -Wdeprecation, that would not have already fixed -Wdefault warnings<br class="">
> about missing fields/methods already…)<br class="">
> <br class="">
> <br class="">
> Cheers,<br class="">
> Joachim<br class="">
<br class="">
-- <br class="">
Adam Gundry, Haskell Consultant<br class="">
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank" class="">https://www.well-typed.com/</a><br class="">
<br class="">
Registered in England & Wales, OC335890<br class="">
27 Old Gloucester Street, London WC1N 3AX, England<br class="">
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>