[ghc-steering-committee] Fine-Grained Unused Warnings (#343)

[Arnaud Spiwack]

I'm in favour.

On Wed, 13 Mar 2024 at 08:50, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> This looks like a good change to me. There is no discussion around the
> breaking implications of this, and only Joachim seems to have
> called them out. E.g. tooling that tries to read GHC's human readable
> output, and do something with that. The improved clarity of the
> error messages though is arguably enough. And as far as breakage is
> concerned, this would only happen to tools that use already a
> fragile pass parsing log output of another program. I hope this won't
> cause too much trouble down the line, and am I favour of this
> proposal.
>
> On Wed, 13 Mar 2024 at 00:51, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I support this.  I worked a lot with the author to make the spec
>> precise.  (It was pretty confusing and incomplete before.)
>>
>> TL;DR: the intent is clear and useful; the details are actually
>> surprisingly tricky.  But (like type inference) users won't really care!
>>
>> Simon
>>
>> On Tue, 12 Mar 2024 at 16:39, Chris Dornan <chris at chrisdornan.com> wrote:
>>
>>> Folks,
>>>
>>> Proposal: Fine-Grained Unused Warnings (#42)
>>> Author: Jakob Brünker
>>> Rendered proposal:
>>> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
>>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
>>> Recommendation: Acceptance
>>>
>>> ## Summary
>>>
>>> The proposal partitions warning about unused identifiers into
>>>
>>> a) bindings that are truly unused (not mentioned anywhere) and
>>> b) bindings that are mentioned exclusively in code that is itself
>>> (transitively) unused,
>>>
>>> and controls the latter with the new flag -Windirectly-unused-binds,
>>> which is enabled by default (to preserve existing behaviour).
>>>
>>> Everybody seems to be in favour of the proposal in general and it has
>>> been extensively revised for clarity and to ensure in interoperates
>>> consistently with the existing warning-flags mechanisms.
>>>
>>> I propose that we accept this proposal if nobody objects by the start
>>> of next week (Monday, 2024-03-18).
>>>
>>> Chris
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240314/9b92a0b2/attachment-0001.html>