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

[Chris Dornan]

> 
>> 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.
> 
> My understanding, based on the motivation section, is that this _is_
> the impetus.

I have read the motivation closely (which makes complete sense to me) but nowhere can I see any suggestion that anyone has observed problems with running code that would have been caught by the proposed severe warnings/errors.

This is not to say that that hasn't happened, just that the proposal (entirely correctly in my view) seems principally concerned with making the language safer and removing a class of footguns.

Maybe if I give a simple example to illustrate. I had a fairly mercifully brief time when I liked to use printf -- it tickled historical attachments in my C programming days when displaying formatted string seemed so much more useful. (Of course I got briefly burnt by this practice -- we now have more expressive alternatives that are also type-safe.)  If everybody agreed that printf was a newbie footgun that we wanted to remove then we could attack this problem by deprecating printf and discouraging its use.

Another situation could arise where changes to Haskell have lead to legacy packages relying on printf blowing up, where its continued presence in the ecosystem was providing a systemic risk, with everyone agreeing that the cleanest way to solve the problem would be to force the compiler to fail to build any package that tried o use printf.  The compiler would do this by default, but somebody who really knew what they were doing, could supply incantations to the compiler that would override this behaviour.

My point here is that the motivating sections for removing a footgun and that for blowing up any existing code that does not adhere to a new discipline looks quite different. Any proposal for tightening up the language to provide better static guarantees is going to be seeking to avoid programs that can fail at runtime. A proposal that seeks to invalidate longstanding packages because of an emergent threat to the ecosystem will need to do more work, documented high-profile failures. The motivation section for #571 doesn't appear (to me at least) to be of this latter kind.

Chris