<div dir="ltr"><div>The problem statement, as I understand it:</div><div><br></div><div style="margin-left:40px">I'm writing a library, with dependency L-1 from where I import X and Y(f). A new version L-2 is released, where X exports (f) as well.</div><div style="margin-left:40px">My CI is set to reject all warnings, and start complaining on L-2. Silencing the warning on L-2 requires some rather gratuitous contortion (import X hiding (f)) just to be able to compile with L-1! (even if we don't require L-1 to compile without warning).<br></div><div dir="ltr"><br></div><div dir="ltr">I'm not really fond of the idea of removing this type of duplicate import warning from -wall, to be honest. But I do agree that we shouldn't have to contort the code that way if the libraries are otherwise completely compatible. The fact that it's easy, by merely silencing a warning on imports to break compatibility with a previous version is not something to be proud of.</div><div dir="ltr"><br></div><div>Therefore <b>I'm in favour</b> of this proposal (albeit reluctantly).</div><div><br></div><div>Oleg Grengrus's comment on the discussion thread makes me think that maybe there should be two different recommended sets of warnings: one for libraries (where compatibility with several versions of a dependency is desirable), and one for applications (where you are typically bound to a single version of your dependencies). Though it's probably too much overhead for a single warning difference between the two.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 16 Jun 2023 at 16:05, Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just for the record, I am also open to refinement of the import-warning toolbox in future but I think this proposal is the best next step.<br>
<br>
Given how straightforward the proposition is, how about we set a week for objections to be raised and move to accept the proposal if none are forthcoming (by Saturday, 2023-06-24).<br>
<br>
Chris<br>
<br>
> On 16 Jun 2023, at 13:33, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> this proposal highlights a fundamental tension with compiler warnings.<br>
> <br>
> If you assume a never changing background of dependencies, then the<br>
> current behavior isn’t too bad: GHC correctly tell you that you can<br>
> remove a line of code, and that is a good thing. I don’t think that<br>
> this is directly what is bothering developers.<br>
> <br>
> But dependencies do change, and exports get moved around, and code that<br>
> wasn’t warning before suddenly warns. And that is what’s annoying!<br>
> <br>
> So there is a tension between “given the current assumptions, your code<br>
> can be improved” vs. “assumptions change”.<br>
> <br>
> I agree that at least in this case (and probably in general) we want<br>
> the -Wall warnings to be reasonably insensitive to dependency changes,<br>
> so that good code stays “good”. Of course this is not a hard rule –<br>
> think of deprecation warnings, but a decent guideline.<br>
> <br>
> Therefore in favor.<br>
> <br>
> <br>
> The proposal mentions as alternative “Relaxed redundant imports”, which<br>
> refines the warnings a bit more. In that alternative, an _duplicate<br>
> explicit import_ is cause for a warning; in Chris’ example that would<br>
> be<br>
> <br>
>   import X (f) -- exports some function @f@<br>
>   import y (f) -- exports the same function @f@<br>
>   g = f<br>
> <br>
> Under the current proposal, this would no longer warn with -Wall, but I<br>
> think it’s silly to not warn here, as even with changing dependencies,<br>
> this is a code smell. I sympathize with the author’s wish to not make<br>
> this more complicated than necessary to achieve the goal (warnings<br>
> about duplicate _implicit_ imports causing headcaches), but would like<br>
> to keep the door open for someone who wants to implement the refined<br>
> version in the future. That would probably entail a<br>
>  -Wduplicate-explicit-import<br>
> flag which can then live in -Wall, but is still compatible with this<br>
> proposal, so all izz well.<br>
> <br>
> <br>
> <br>
> Adam points out (as quoted in the proposal) that users of<br>
>   -Weverything -Wno-unused-imports<br>
> might see new breakage. I don’t think someone using -Weverything can<br>
> expect any kind of stability, else we paint ourselves into a corner (or<br>
> start introducing -Wreally-everything, -Wreally-really-everything, …)<br>
> <br>
> <br>
> Cheers,<br>
> Joachim<br>
> <br>
> <br>
> <br>
> <br>
> Am Donnerstag, dem 15.06.2023 um 16:50 +0100 schrieb Chris Dornan:<br>
>> Dear Committee,<br>
>> <br>
>> Georgi Lyubenov has a simple proposal to improve the quality of life for many package maintainers that I recommend that we accept.<br>
>> <br>
>> ## Split -Wunused-imports<br>
>> <br>
>> Rendered proposal: <<a href="https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md" rel="noreferrer" target="_blank">https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md</a>><br>
>> Discussion of proposal: <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/586" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/586</a>><br>
>> <br>
>> ### Summary<br>
>> <br>
>> (Straight from the proposal.)<br>
>> <br>
>> We propose to split the -Wunused-imports warning into two parts:<br>
>> <br>
>> - warn on actual unused imports<br>
>> - warn on duplicate imports<br>
>> <br>
>> while also not including the second in -Wall. This will greatly reduce "churn" for library authors.<br>
>> <br>
>> <br>
>> ## In more Detail<br>
>> <br>
>> As we know, many Haskell developers, including significant commercial projects, incorporate -Wall<br>
>> -Werror into their workflow at some stage. To this end it is important that we minimise 'false<br>
>> negatives', whereby the compiler emits 'frivolous' warnings.<br>
>> <br>
>> This proposal identifies an important class of -Wall warnings that many package maintainers<br>
>> appear to regard quite bothersome, namely when the compiler warns that import statement is <br>
>> superflous even when it is importing an entity that is being used by the module. The issue is<br>
>> the way `-Wunused-imports` works, which will issue a warning for the following program.<br>
>> <br>
>> ```haskell<br>
>> import X -- exports some function @f@<br>
>> import y -- exports the same function @f@<br>
>> <br>
>> g = f<br>
>> ```<br>
>> <br>
>> The compiler will warn that the second Y import is redundant.<br>
>> <br>
>> Many developers do not want to be warned about this. As far as they are concerned each import is<br>
>> yielding enties that are in use and the fact that one of them can be removed is just not <br>
>> interesting.<br>
>> <br>
>> In contrast, developers that use -Wall do want to be warned about the following.<br>
>> <br>
>> ```haskell<br>
>> import X -- exports some function @f@<br>
>> import Z -- does not export f<br>
>> <br>
>> g = f<br>
>> ```<br>
>> <br>
>> Here our module has a completely false dependency on Z which should be cleaned up at the point that<br>
>> warnings are cleaned up.<br>
>> <br>
>> This proposal proposes modifying -Wunused-imports so that it will warn about the second example but<br>
>> stay silent for the first, and adds a -Wduplicate-imports that will issue a warning for the the<br>
>> first example. In effect the enabling of both warnings in the new proposal will restore the current<br>
>> -Wunused-imports behaviour. -Wall should *not* enable -Wduplicate-imports but is avilable to those<br>
>> developers that rely on the current behaviour of -Wunused-imports (which some clearly do).<br>
>> <br>
>> <br>
>> ## Recommendation<br>
>> <br>
>> I recommend that we accept this proposal.<br>
>> <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>
>> <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>
> -- <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>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><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>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><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>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div></div>