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

[Simon Marlow]

On Thu, 21 Sept 2023 at 13:51, Richard Eisenberg <lists at richarde.dev> wrote:

> I will mull on the actual proposal (I feel there is a solution somewhere
> here that we haven't hit yet), but I wanted to respond to Simon M's comment
> about deferred cost: The migration cycle is more than just a deferment:
> it's a smearing. That is, if something breaks suddenly, everyone must
> upgrade in unison: hard. If something breaks slowly, then people can update
> their projects when they choose during the migration period: much easier.
> That difference might not affect an enterprise all that much, but I think
> it has a sizable impact on open-source developers.
>

Yes you're right, and I'm reluctant to further derail this thread but I
think it's important to note that as the volume of changes increases, the
cost of upgrades increases with it, and so the frequency of upgrades
reduces, which nullifies the benefits of smearing the cost of a change with
deprecations. Eventually, some customers are jumping over so many releases
at once that they miss all the intermediate deprecations. This is the
reality where I work, and I believe other companies too.

Cheers
Simon


> Richard
>
> On Sep 21, 2023, at 8:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> I might be an outlier here, but deferring the change to a later release
> and adding an intermediate warning doesn't make it any less bad.
>
> This is one cultural aspect of our community I'd like to shift: the
> expectation that it's OK to make breaking changes as long as you warn about
> them or go through a migration cycle. It just isn't! (and I speak as
> someone who used to make lots of changes, I'm now fully repentant!). That's
> not to say that we shouldn't ever change anything, but when considering the
> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
> just defers it.
>
> Cheers
> Simon
>
>
>
> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>
>> I agree with Joachim's position here.
>>
>> Having a -Wsevere group at all would be a good start, but the problem
>> with stopping at "best-practice guidance" rather than changing the
>> defaults is that it benefits only those who learn about and follow the
>> guidance. So it remains a footgun for newcomers.
>>
>> Regarding migration, given that GHC has issued these warnings by default
>> for some time, I don't think we need be too shy about upgrading their
>> severity. We could have -Wcompat imply -Werror=severe, but that
>> complicates the semantics of warning groups, and will help only those
>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>
>> I suppose as Moritz suggests we could introduce and advertise -Wsevere
>> in 9.10, and mention in the warning message that this will be an error
>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
>> 9.10 would give something like:
>>
>> M.hs:8:10: warning: [-Wmissing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • This will become an error by default in a future GHC release;
>>        use -Werror=severe to make severe warnings into errors now.
>>
>> Then in a future release:
>>
>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • Use -Wwarn=missing-methods to permit this anyway.
>>
>> Would that be a reasonable compromise?
>>
>> Adam
>>
>>
>> On 19/09/2023 22:13, Joachim Breitner wrote:
>> > 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
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230922/dd95db25/attachment-0001.html>