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

[Chris Dornan]

If I understand you rightly, you are arguing that any legacy packages that would flag severe warnings should now fail to compile, even if they are marked as being (say) Haskell2010? For reasons I have given (I have no wish to be repetive), that strikes me as undesirable. If the impetus for the proposal was driven by observed problematic failures of packaged code that could be caught by these warnings then, for me, there would be a discussion to be had. But my understanding is that the proposal is driven by a desire to tighten up the language moving forward with severe warnings treated as errors by default. Maybe one of the authors could say which they intended.

Chris

> On 9 Oct 2023, at 13:16, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> 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/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee