Skip to content

GitLab

GHC
GHC
Last edited by Ben Gamari
Page history New page

wcompat

-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 or Monoid instances declarations are detected (e.g. Monoid(mappend) not defined in terms of Semigroup((<>)))

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,

  1. 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
  1. 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: 
  ghc-options: -Wall
  if impl(ghc >` 8)
     ghc-options: -Wno-compat

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