<div dir="ltr"><div>Hello Café,<br><br></div><div>TL;DR: should the deprecation GHC option be transitively reported for re-exported definitions?</div><div><br></div><div>I have a library that is exposing too much. As a minimal example, say the library contains:</div><div>- Module A, which defines several functions and types.<br></div><div>- Module B, which exports <i>specific definitions</i> from module A and has none of its own.</div><div><br></div><div>It so happens that, to keep things as clean and abstract as possible, only module B should be exposed.</div><div><br></div><div>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.<br></div><div><br></div><div>My expectation was that library users who imported <i>A directly</i> would get a warning, but importing definitions in A <i>via B</i> would not give out any warnings.<br></div><div><br></div><div>That, however, is not what is happening:</div><div><br></div><div><span style="font-family:monospace">In the use of ‘functionInA’<br>    (imported from B, but defined in A):<br>    Deprecated: "This module will be hidden in future versions."</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><span style="font-family:arial,sans-serif">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.)</span><br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><span style="font-family:arial,sans-serif">However, more generally, if you use a function from A in a NEW function definition in B and then export <i>that second definition instead</i>, the compiler won't tell <i>the library user</i> 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.<br></span></span></div><div><span style="font-family:monospace"><span style="font-family:arial,sans-serif"><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:arial,sans-serif">So I ask: should deprecation work the way it is working in the first place?</span></span></div><div><br></div><div>All the best,</div><div><br></div><div>Ivan<br></div><div><span style="font-family:monospace"><span style="font-family:arial,sans-serif"><span style="font-family:monospace"><span style="font-family:arial,sans-serif"></span></span></span></span></div></div>