-Wcompat
warnings
With GHC 8.0 we have implemented a new warning-group -Wcompat
(see
#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 -Wcompat
,
-Wmissing-monadfail-instances
Warn when a failable pattern is used in a do-block that does not have a
MonadFail
instance.
-Wsemigroup
Warn when definitions are in conflict with the future inclusion of
Semigroup
into the standard typeclasses.
-Wnoncanonical-monoid-instances
Warn if noncanonical
Semigroup
orMonoid
instances declarations are detected (e.g.Monoid(mappend)
not defined in terms ofSemigroup((<>))
)
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 -Wcompat
in -Wall
. We refer to these options as,
- Opt-in style (
-Wall
does not include-Wcompat
):
- Users who desire warnings about upcoming changes would use
-Wall -Wcompat
- Users who dislike such warnings could use
-Wall
- Opt-out style (
-Wall
includes-Wcompat
):
- Users who desire warnings about upcoming changes could use
-Wall
- Users who dislike such warnings would use
-Wall -Wno-compat
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
-Wcompat
by 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). |
---|
In requesting
-Wall
the 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
-Wcompat
is not in-Wall
:
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-Wall
),
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.
However, when
-Wcompat
warnings 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 |
---|