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.-IavorOn 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
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- steering-committee