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@joachim-breitner.de http://www.joachim-breitner.de/