
Hi,
in fact, GHC knows how something is imported; it uses this information to report redundant imports. So I can optimistically hope that the implementation effort is reasonable.
Cheers,
Joachim
Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki
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
wrote: Hi,
alanasp has proposed a Deprecating Exports mechanism:
https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
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