[Haskell-cafe] Deprecation being transitively reported for re-exported definitions
Ivan Perez
ivanperezdominguez at gmail.com
Sun Aug 15 01:22:31 UTC 2021
Hello Café,
TL;DR: should the deprecation GHC option be transitively reported for
re-exported definitions?
I have a library that is exposing too much. As a minimal example, say the
library contains:
- Module A, which defines several functions and types.
- Module B, which exports *specific definitions* from module A and has none
of its own.
It so happens that, to keep things as clean and abstract as possible, only
module B should be exposed.
As per library policy, we give users time to adapt. A way to do that would
be to deprecate module A, but configure B to ignore deprecations
(-Wno-deprecations) so GHC does not complain during the compilation of the
library itself.
My expectation was that library users who imported *A directly* would get a
warning, but importing definitions in A *via B* would not give out any
warnings.
That, however, is not what is happening:
In the use of ‘functionInA’
(imported from B, but defined in A):
Deprecated: "This module will be hidden in future versions."
There are "workarounds": I could move all definitions in A to new module C,
deprecate A, and re-export C in B, or I could re-define the exported
definitions in B as identities of those in A (easy for functions, probably
more cumbersome for data constructors or classes.)
However, more generally, if you use a function from A in a NEW function
definition in B and then export *that second definition instead*, the
compiler won't tell *the library user* that B is internally relying on a
deprecated function. Reexporting a function without changes could
conceptually be seen as an "extreme" case of that, where where the name and
the implementation in B coincide with those in A.
So I ask: should deprecation work the way it is working in the first place?
All the best,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210814/72ed04aa/attachment.html>
More information about the Haskell-Cafe
mailing list