I have a bunch of question about this proposal, but I wrote them on the proposal discussion page, as this is what folks asked for, last time I had some questions. I think answering them would make the proposal more clear.

It seems to me that the use of this extension is somewhat limited, but it could be useful on occasion so I could take it or leave it. It's been a while since I've looked at the GHC source, but I don't think that implementing this would be completely trivial, as I don't thing GHC currently cares about *how* names came to in scope, just what they refer to. But, I believe this is usually not a big factor in our discussions, just though I'd mention it.

-Iavor

On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail@joachim-breitner.de> wrote:

Hi,

alanasp has proposed a Deprecating Exports mechanism:
https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst

The gist is explained by this:

module Data.List
( ...
{-# DEPRECATE lines "Exported from Data.String instead" #-}
, lines
...t
) where

i.e. DEPRECATE pragmas in export lists cause warning when some other
module uses the deprecated symbol when it is imported (only) via some
deprecated export.

This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de
Castro Lopo.

The feature has a clear use-case, is self-contained and David Feuer
(the containers maintainer) has already confirmed that there is a real
demand for this. I suggest acceptance!

As always, I will understand silence as tactic consensus.

Cheers,
Joachim

--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee