<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 14 Aug 2021 at 23:00, Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi" target="_blank">oleg.grenrus@iki.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <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></p></div></blockquote><div><br></div><div>This was also my understanding AFTER I saw the unexpected warning.</div><div><br></div><div>So, you can say that <i>a definition within a module is deprecated</i>, and that <i>a module AND ALL definitions in it are deprecated. </i>However<i>, </i>you cannot express that<i> the module (name) itself is deprecated without deprecating what's in it</i>. It's just a level of expressiveness we do not have.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">If module deprecation did not lead to what you labeled (2), you could still deprecate everything in it to warn users of deprecated functions that are being re-exported through a different path. So you could obtain the same effect as now, by just annotating specific definitions.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Ivan<br></div><div class="gmail_quote"><div><br></div></div></div>