Move deprecated modules to undeprecated hidden modules #213
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #209, obviates #211.
Problem
Given the modules:
We want the following to succeed without warnings:
Unfortunately we receive a deprecation warning for the usage in
Z
even though we imported a(n ostensibly non-deprecated) symbol from a non-deprecated symbol. The problem is that any symbol (foo
) defined in a deprecated module (X
) inherits the deprecation.Solution
The strategy here is outlined in this comment: #209 (comment)
We move
X
's implementation into the non-deprecated but hiddenX.Hidden
.X
retains its deprecation, merely re-exportingX.Hidden
.Now, this succeeds as we would like:
And this fails:
This PR also changes internal usage of deprecated modules to use the new hidden ones. This removes the need to litter the codebase with
{-# OPTIONS_GHC -Wno-deprecations #-}
, to avoid internal warnings.It is recommended to review the commits individually, as the overall diff is large. The first commit merely renames modules
X -> X.Hidden
. The second adds backX
with deprecation message, and removes the deprecation fromX.Hidden
.