With GHC 8.0 we have implemented a new warning-group
#11000 (closed)) which includes warnings that will be enabled by default in the
future, but remain off in normal compilations for the time
being. This allows library authors eager to make their code future
compatible to adapt to new features before they even generate
warnings, and even later turn into actual compile errors.
In the case of GHC 8.0.1 there will be three warnings in
Warn when a failable pattern is used in a do-block that does not have a
Warn when definitions are in conflict with the future inclusion of
Semigroupinto the standard typeclasses.
Warn if noncanonical
Monoidinstances declarations are detected (e.g.
Monoid(mappend)not defined in terms of
Of course, in order for this new group to be effective in bringing coming changes to light, people must to use it. One way to encourage this would be to add
-Wcompat to the widely used
-Wall group (tracked as #11494 (closed)).
This page describes some arguments for and against including
-Wall. We refer to these options as,
- Opt-in style (
-Walldoes not include
- Users who desire warnings about upcoming changes would use
- Users who dislike such warnings could use
- Opt-out style (
- Users who desire warnings about upcoming changes could use
- Users who dislike such warnings would use
Arguments for opt-out style
|Improved discoverability of -Wcompat||Most users know mostly about -Wall but not about -Wcompat, and even if -Wcompat becomes better known, maybe they won't bother (or simply forget) to turn on -Wcompat.|
The most effective way to reach everybody is by enabling
-Wcompatby default and have them opt-out if they don't like it.
|The additional warnings won't cause build issues unless -Werror is enabled||This means that the change won't cause problems for Hackage since Hackage rejects packages with -Werror anyway).|
-Wallthe user is requesting an inclusive set of warnings that may not be stable over compiler version.
|The user may expect that -Wall enables all warnings known to GHC||Adding more ad-hoc exceptions than already exist further breaks this expectation.|
|Avoids stretching out library proposal by an additional major GHC release|
In order to comply with the notion to give developers a release worth of notice, this requires to wait an additional GHC release beyond what the 3-release policy demands. This effectively means that a proposal requires to wait for the completion of a 4 year roadmap when
-Wcompatis not in
Proposal gets accepted and starts getting integrated into GHC HEAD in 2015,
GHC 8.0 (2016) starts including forward-compatibility warning in
-Wcompat(but not in
GHC 8.4 (2018) starts warning about forward-compatibility without
-Wcompat, and finally
GHC 8.6 (2019) turns the warning into an error and thereby completes the proposal implementation.
-Wcompatwarnings are on by default, the timeline can be pushed up and be completed one year earlier by GHC 8.4.
Arguments for opt-in style
|Users of -Wall will need Cabal file boilerplate to disable -Wcompat||
Packages that insist on -Wall cleanliness while supporting pre-GHC-8.0 need to add boilerplate
in their cabal files to silence compatibility warnings:
However, as previously, -Wall is intended for use during development. Therefore, we discourage the use of -Wall in released projects.
|Inclusion in -Wall raises the bar for including new warnings in -Wcompat||Having -Wcompat separate from -Wall allows us to include more verbose warnings to -Wcompat that would be questionable in -Wall|
|-Wcompat warnings aren't necessarily actionable||-Wcompat warnings aren't necessarily actionable if backwards compatibility is desired; if they were, they'd be in -Wall. The point of -Wcompat was to give notice to folks who wanted them as soon as possible, even if they were things they couldn't do, yet moving them into -Wall means that this whole thing becomes a big mess of active maintenance|