On Sat, 14 Aug 2021 at 23:00, Oleg Grenrus
I think the confusion stems from what the deprecation of the module means, i.e.
module A {-# DEPRECATED "This module will be hidden in future versions". #-} ( ... ) where
I think it does two things:
1. deprecates the module A, so if it's imported anywhere, the deprecation warning will be reported 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 "..." #-}.
This was also my understanding AFTER I saw the unexpected warning. So, you can say that *a definition within a module is deprecated*, and that *a module AND ALL definitions in it are deprecated. *However*, *you cannot express that* the module (name) itself is deprecated without deprecating what's in it*. It's just a level of expressiveness we do not have. 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. Ivan