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