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

[Joachim Breitner]

Hi,

Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:
> By putting the new behaviour in GHC2024, users can choose when to
> update their code to accommodate the change.

almost. Users choose when to update _their_ code to a new language
edition, but not when their dependencies are updated.

For most proposals, I’d fully agree that going via a new language
extension, possibly on by default in a future GHC20xx, is the way to
go. But in this _particular_ case, we have that the main driving
motivation is that we really want libraries to stop building if their
dependencies have introduced new methods. These libraries are very
likely not going to use GHC2024 any time soon: 

Firstly, because libraries can’t upgrade to new GHC20xx as quickly as
programs can, because they want to support older versions of GHC.

But secondly, because this quality control of “build fails when things
are likely wrong” is especially important for less-actively maintained
libraries.

Changes tied to language pragmas only affect those modules/libraries
that want to be affected. This is great in general, but not helpful for
changes that need to apply to _all_ modules/libraries.

So it seems that the present use case is only well addressed if `-
Werror=missing-methods` becomes a default in a future GHC version
_independent_ of the language model. The stability document has a
provision vor this: 

> (GR2) We may break (GR1), but only with a compelling reason, and with
> careful consideration of impact..


I suggest we first focus on this question: Does the proposed change
should fall under this exception and be rolled out (with deprecation)
globally.
If yes, we do that.
If not, we can then ponder if this change is still useful as part of a
future GHC20xx, or not worth the bother then.


Cheers,
Joachim


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