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
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-... ):
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 Rendered:
https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s...
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/blob/wsevere/proposals/0000-s...
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
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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee