[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)

[Joachim Breitner]

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
> Maybe implementing this "severe" category, but not changing its
> default to error, would get us some of the way there?  Then "best-
> practice guidance" could be "use -Werror=severe", and job done. 
> That's a bit easier to say than saying "use -Werrror=missing-methods
> -Werror= ..." etc.

anyone using `-Werror` would already get this behavior. So what is the
useful for using `-Werror=severe` instead? Presumably the rationale is:

 -Werror, while great _during_ development or in leaf packages, is not
 is not good idea in _released_ code, i.e. code that is compiled by 
 others, as that code needs to keep working even as compilers and
 dependencies change, such as libraries on hackage, or executables
 built by distro packagers.
 That’s why -Werror is frowned upon there.

 But some changes in upstream packages _ought_ to cause compilation to
 fail, because they really need downstream code changes. These will
 cause severe warnings, and therefore -Werror=severe is desirable
 even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as
severe warnings, it totally fits this description: It would be
_possible_ to keep compiling the downstream code, but it would not be
desirable. That's why compilation fails, and that’s why we don’t defer
type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate
if we cannot make it the default. If not right away, then maybe with a
suitable migration strategy? (Although I wonder if there are many users
out there that pay attention to deprecation warnings, e.g. watch
-Wdeprecation, that would not have already fixed -Wdefault warnings
about missing fields/methods already…)


Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/