[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)
Simon Marlow
marlowsd at gmail.com
Thu Oct 5 17:07:09 UTC 2023
Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using
pre-GHC2021 myself).
In that case, I'm suggesting that we enable -Werror=severe in the next
GHC20xx iteration, and leave GHC2021 etc. unaffected.
Cheers
Simon
On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com> wrote:
> On 04/10/2023 22:04, Simon Marlow wrote:
> > My concrete suggestion is we EITHER
> >
> > * Enable -Werror=severe in future GHC20xx versions only, or
> > * Enable it by default and in future GHC20xx versions, but not in
> > GHC2021, Haskell2010, or Haskell98
>
> Sorry, I don't quite understand the difference between these options.
> What does it mean to enable -Werror=severe by default but not in
> GHC2021, given that GHC2021 is the (current) default?
>
> Cheers,
>
> Adam
>
>
> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >
> > I must say that I am strongly influenced by the fact that
> >
> > * Matt Parsons
> > * Andrew Lelechenko (bodigrim)
> >
> > are both not just in favour, but *strongly *in favour. They must
> > think of the case as compelling, because they are both usually very
> > careful about unnecessary breakage.
> >
> > if we make -Werror=severe the default, then any new warning
> > added to -Wsevere is a new breaking change, and we would have to
> > judge it to be compelling enough by GR2
> >
> >
> > Yes indeed. But that's not a bug -- it's a feature.
> >
> > To be clear I have no strongly held opinion myself. Perhaps we
> > should canvas opinion among people using Haskell in production? We
> > did so with CLC but we could do so publicly.
> >
> > Simon
> >
> > On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
> > <mailto:marlowsd at gmail.com>> wrote:
> >
> > I don't think this breaking change (namely making -Werror=severe
> > the default) meets the bar for "compelling reason" according to
> > GR2 of our proposed policy, so I'm voting against. It's
> > certainly not a bug or a security hole. Maybe you could argue
> > that it's a design flaw in the language, but I'm not all that
> > convinced. It's an unforced breaking change in my opinion. If we
> > add "makes it more difficult to shoot yourself in the foot" a
> > compelling enough reason to break GR1 then I think we've
> > weakened it significantly.
> >
> > Here's another problem: if we make -Werror=severe the default,
> > then any new warning added to -Wsevere is a new breaking change,
> > and we would have to judge it to be compelling enough by GR2. If
> > we don't make -Werror=severe the default, then we're not
> > restricted in what we can add to -Wsevere. Probably -Wsevere
> > would end up being more useful as a result.
> >
> > Cheers
> > Simon
> >
> >
> > On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
> > <simon.peytonjones at gmail.com
> > <mailto:simon.peytonjones at gmail.com>> wrote:
> >
> > Here's my summary:
> >
> > * There is strong (universal, even) support for the
> > `severe` category.
> > * There is pretty strong support for making severe
> > warnings into errors at some point. As Matt puts it
> > "this is not a question of GHC breaking things, but
> > rather /revealing/ and providing early-diagnosis for
> > /already broken/ things".
> > * But I think we are moving towards a policy of giving
> > users time to adapt via a deprecation cycle, whenever
> > that is feasible. And it is feasible here.
> >
> > So my suggestion would be:
> >
> > * When implemented, make `-Wwarn=severe` the default, but
> > add to each severe warning a deprecation-style message
> > saying that it'll become an error in the next iteration.
> > * In the next released, make `-Werror=severe` the default.
> > * Don't complicate matters by involving GHC2024. That is
> > another conversation, and even if we wanted to include
> > `-Werorr=severe` in GHC2024, we would *still* want a
> > deprecation cycle!
> >
> > Would that be acceptable?
> >
> > Simon
> >
> > On Fri, 29 Sept 2023 at 19:41, Adam Gundry
> > <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> >
> > Dear Committee,
> >
> > It seems we are somewhat split on the -Wsevere proposal,
> > even assuming
> > it is introduced with a deprecation period (changing the
> > warning text
> > and adding the group in advance). There is consensus
> > that adding the
> > group by itself is fine, and potentially enabling
> > -Werror=severe under
> > GHC2024, but enabling it by default for existing code is
> > more controversial.
> >
> > Ultimately this is a judgement call about the value of
> > the proposal
> > versus the breakage it causes. I remain of the view that
> > it is
> > worthwhile. This is not merely about more aggressively
> > enforcing best
> > practice. Rather, it eliminates the risk of the
> following:
> >
> > * Suppose package A defines a type class, package B
> > depends on package
> > A, and package C depends on package B.
> >
> > * Now package A extends the type class definition with a
> > new method and
> > default methods. Everything still compiles; package B
> > now issues a
> > -Wmissing-methods warning (but is not actively
> > maintained, and the
> > author of package C is unlikely to look at warnings in
> > all their
> > dependencies).
> >
> > * Users of package C have to try to debug an infinite
> loop.
> >
> > Given that this change avoids a significant issue,
> > affected code has
> > been issuing warnings for many years, and impacted users
> > can very easily
> > set -Wwarn=severe either at the package level or the
> > project level, I
> > think is worth accepting the backwards compatibility
> > cost and the fact
> > that some Haskell2010 code will no longer be accepted by
> > default.
> >
> > Matt Parsons puts it well in the CLC thread, which is
> > pretty clearly in
> > favour of this proposal overall
> > (
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> <
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> >):
> >
> > > I think GHC should strive to make fewer breaking
> > changes, and make
> > those changes as easy-to-adopt as possible. But this is
> > not a question
> > of GHC breaking things, but rather revealing and
> providing
> > early-diagnosis for already broken things.
> >
> > Further opinions are welcome, of course.
> >
> > Adam
> >
> >
> > On 14/09/2023 09:32, Adam Gundry wrote:
> > > Dear Committee,
> > >
> > > Joachim, along with Oleg Grenrus, proposes to change
> > -Wmissing-methods
> > > and -Wmissing-fields warnings into errors by default
> > (retaining the
> > > option to downgrade them). I recommend we accept the
> > proposal.
> > >
> > > Proposal:
> > https://github.com/ghc-proposals/ghc-proposals/pull/571
> > <https://github.com/ghc-proposals/ghc-proposals/pull/571
> >
> > > Rendered:
> > >
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> > >
> > > This is primarily motivated by the fact that when
> > classes have default
> > > methods, missing methods can lead to runtime loops,
> > which are generally
> > > difficult to debug. Since in practice not all users
> > pay attention to
> > > warnings that do not inhibit compilation, it makes
> > sense to identify a
> > > class of warnings that are sufficiently serious to
> > require explicit
> > > action from the user to silence them.
> > >
> > > Since these warnings are currently not errors by
> > default, library
> > > authors experimentally assessing the impact of
> > changes may be lead to
> > > assume that introducing new methods/fields does not
> > lead to breakage
> > > (because downstream code will still compile). The
> > proposal thus makes it
> > > more obvious that adding a new method or field is a
> > breaking change.
> > >
> > > The proposal deliberately causes builds to fail by
> > default for some
> > > libraries that currently emit warnings. Oleg has
> > kindly performed impact
> > > assessments to identify such libraries, and the
> > breakage of a few
> > > packages seems worth the cost.
> > >
> > > It is easy to restore the warnings to their previous
> > classification by
> > > passing an option at build time, e.g. using
> > -Wno-error=missing-methods.
> > > Users can set such an option in cabal.project or
> > stack.yaml to work
> > > around breakage that is not promptly fixed by the
> > library author.
> > >
> > > This change does mean that GHC with -XHaskell98/2010
> > will by default
> > > reject some programs that are explicitly permitted by
> > the Haskell98/2010
> > > specification. I recommend we document this
> > infelicity, but accept it,
> > > as much of the benefit of the proposal is that it
> > applies by default.
> > >
> > > The proposal establishes the precedent that some
> > warnings may be treated
> > > as errors by default, and introduces a warning group
> > -Wsevere to
> > > classify them. This seems conceptually useful and
> > gives us the option to
> > > extend the -Wsevere set in the future (e.g. as a
> > final stage of
> > > deprecation before a feature is removed).
> > >
> > > Thoughts?
> > >
> > > Adam
> > >
> > >
> > > On 11/09/2023 20:25, Joachim Breitner wrote:
> > >> Dear Committee,
> > >>
> > >> based on suggestions by Oleg Grenrus, I wrote a
> > proposal to introduce a
> > >> warning group -Wsevere for on-by-defaults,
> > error-by-default warnings,
> > >> and initially fill it with missing-methods and
> > missing-fields.
> > >>
> > >>
> > >>
> > https://github.com/ghc-proposals/ghc-proposals/pull/571
> > <https://github.com/ghc-proposals/ghc-proposals/pull/571
> >
> > >>
> > >>
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> > >>
> > >> I’d like to nominate Adam as the shepherd, who
> > already reviewed it a
> > >> bit on Github.
> > >>
> > >> Please guide us to a conclusion as outlined in
> > >>
> >
> https://github.com/ghc-proposals/ghc-proposals#committee-process <
> https://github.com/ghc-proposals/ghc-proposals#committee-process>
> > >>
> > >>
> > >> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231005/c4beb3d2/attachment-0001.html>
More information about the ghc-steering-committee
mailing list