<div dir="ltr">Aha, yes, I see that `GlobalRdrElement` has a list of imports that caused it to come in scope.  I guess then the main change in types would be to `IfaceExport`, which is currently just an `AvailInfo` to something that would keep track of what's deprecated.  Seems doable.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 24, 2018 at 10:35 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>>:<br>
>I have a bunch of question about this proposal, but I wrote them on the<br>
>proposal discussion page, as this is what folks asked for, last time I<br>
>had<br>
>some questions.   I think answering them would make the proposal more<br>
>clear.<br>
><br>
>It seems to me that the use of this extension is somewhat limited, but<br>
>it<br>
>could be useful on occasion so I could take it or leave it.    It's<br>
>been a<br>
>while since I've looked at the GHC source, but I don't think that<br>
>implementing this would be completely trivial, as I don't thing GHC<br>
>currently cares about *how* names came to in scope, just what they<br>
>refer<br>
>to.   But, I believe this is usually not a big factor in our<br>
>discussions,<br>
>just though I'd mention it.<br>
><br>
>-Iavor<br>
><br>
><br>
><br>
><br>
>On Thu, May 24, 2018 at 3:23 AM Joachim Breitner<br>
><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
>wrote:<br>
><br>
>> Hi,<br>
>><br>
>> alanasp has proposed a Deprecating Exports mechanism:<br>
>><br>
>><br>
><a href="https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst" rel="noreferrer" target="_blank">https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst</a><br>
>><br>
>> The gist is explained by this:<br>
>><br>
>>    module Data.List<br>
>>    (  ...<br>
>>        {-# DEPRECATE lines "Exported from Data.String instead" #-}<br>
>>        , lines<br>
>>        ...t<br>
>>    ) where<br>
>><br>
>> i.e. DEPRECATE pragmas in export lists cause warning when some other<br>
>> module uses the deprecated symbol when it is imported (only) via some<br>
>> deprecated export.<br>
>><br>
>> This is a GSOC 2018 project, mentored by Matthew Pickering and Erik<br>
>de<br>
>> Castro Lopo.<br>
>><br>
>> The feature has a clear use-case, is self-contained and David Feuer<br>
>> (the containers maintainer) has already confirmed that there is a<br>
>real<br>
>> demand for this. I suggest acceptance!<br>
>><br>
>><br>
>> As always, I will understand silence as tactic consensus.<br>
>><br>
>> Cheers,<br>
>> Joachim<br>
>><br>
>><br>
>> --<br>
>> Joachim Breitner<br>
>>   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
>>   <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
>> _______________________________________________<br>
>> ghc-steering-committee mailing list<br>
>> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>><br>
><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
>><br>
</blockquote></div>