<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I think the confusion stems from what the deprecation of the
module means, i.e.<br>
<br>
module A {-# DEPRECATED "This module will be hidden in future
versions". #-} ( ... ) where<br>
<br>
I think it does two things:<br>
<br>
1. deprecates the module A, so if it's imported anywhere, the
deprecation warning will be reported<br>
2. deprecates all symbols defined in the module, so the use-sites
are reported as well. (This is like deprecating an individual
binding, {-# DEPRECATED symbolInA "..." #-}.<br>
<br>
The second point is why re-exporting names defined in A still
causes the warning. The thing is deprecated, it doesn't matter how
you import it.<br>
However, if A re-exports some other symbols (e.g. from
A.Internal), these things are not deprecated, and thus no
warnings.<br>
<br>
This explains why a workaround you mention works. Or we could even
argue that the (first) workaround is not even a workaround, but
the right way to do what you want.<br>
<br>
Defining new binding is not the same as re-exporting. There is a
bit discussion about it in [1], e.g. users can define different
RULES for the thing "renamed" in B.<br>
<br>
There is an interesting challenge in [1] too: <br>
<br>
> the proposal would be stronger if it explicitly explained
that much of what is proposed [renaming on import] could be done
with existing mechanisms [like writing new definitions, type,
etc.]<br>
<br>
For your use case (in second workaround) you'll rely that
redefinition (as "heavy" renaming) will strip the deprecation bit.
But we can argue that it's still a renaming, so it should not! :)<br>
<br>
[1]:
<a class="moz-txt-link-freetext" href="https://github.com/ghc-proposals/ghc-proposals/pull/408#issuecomment-806064864">https://github.com/ghc-proposals/ghc-proposals/pull/408#issuecomment-806064864</a><br>
<br>
- Oleg<br>
</p>
<div class="moz-cite-prefix">On 15.8.2021 4.22, Ivan Perez wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACZKWEJwD6E1oHsi_U0YPboTN+eKwqXwvNP9jt3Rb4QXzXk84Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
</blockquote>
</body>
</html>