[ghc-steering-committee] Please review #516: Introduce `-Wincomplete-record-selectors`, Shepherd: Eric

[Simon Peyton Jones]

I'm happy to accept this proposal too.

I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement
>

What is "Simon's refinement".  I think you are referring to :
-
>
> I'd prefer if -wpartial-record-selectors and -wpartial-record-updates were
> in -Wall

- but in fact that's what the proposal says, I believe.
-
- Simon

On Sat, 17 Sept 2022 at 18:51, Chris Dornan <chris at chrisdornan.com> wrote:

> +1 to this: I’m  happy with Adam’s tweaked proposal, or better with
> Simon’s refinement.
>
> > On 2022-09-17, at 16:30, Eric Seidel <eric at seidel.io> wrote:
> >
> > Adam has updated the proposal to include the new
> -Wincomplete-record-selectors in -Wall (as it turns out
> -Wincomplete-record-updates was already included.
> >
> > He also added a section providing a rationale for keeping the naming
> as-is, notably separate from -Wpartial-fields (which disallows the
> *definition* of partial record selectors).
> >
> >
> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst#naming
> >
> > I think this is a reasonable place to land, and recommend accepting the
> proposal in its current state.
> >
> > Any objections?
> >
> > On Wed, Sep 7, 2022, at 18:05, Simon Peyton Jones wrote:
> >> I'd be happy to accept this one.
> >>
> >> In fact I'd prefer it if
> >> * -wpartial-record-selectors and -wpartial-record-updates were in -Wall
> >> * But -wpartial-fields should definitely not be in -Wall because there
> >> is absolutely nothing wrong with using named fields to help with
> >> pattern matching and record construction -- places were partiality is
> >> not an issue
> >> Simon
> >>
> >> On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev>
> wrote:
> >>> I also lean toward acceptance.
> >>>
> >>> However, I'm a little worried about the flourishing of warnings not in
> -Wall. Ignoring -Weverything -- which tends to be over the top, even for
> the paranoid -- all of the extra warnings have to be enabled independently.
> Does it make sense to try to bring some structure to this area? Or maybe we
> say "no" and leave it to IDEs to impose that structure. Actually, I've
> already argued myself into that latter camp.
> >>>
> >>> In any case, I vote to accept this proposal.
> >>>
> >>> Richard
> >>>
> >>>> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >>>>
> >>>> The proposal makes sense to me. I don't have a strong opinion, but
> I'm leaning towards acceptance.
> >>>>
> >>>> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
> >>>>> Dear Committee,
> >>>>>
> >>>>> Adam Gundry has proposed a new warning
> -Wincomplete-record-selectors[1] that would flag occurrences of partial
> record selectors, e.g. the field `x` in
> >>>>>
> >>>>> ```
> >>>>> data T = T1 { x :: Int, y :: Bool }
> >>>>>       | T2 { y :: Bool }
> >>>>> ```
> >>>>>
> >>>>> The proposal is well-specified, will never warn about total
> selectors (e.g. `y` above), and allows for a smarter compiler to suppress
> warnings in cases where a partial selector is used in a total context (e.g.
> `x (T1 42 True)`).
> >>>>>
> >>>>> I recommend acceptance.
> >>>>>
> >>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
> >>>>>
> >>>>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
> >>>>>> Dear Committee,
> >>>>>>
> >>>>>> Introduce `-Wincomplete-record-selectors`
> >>>>>> have been submitted by Adam Gundry
> >>>>>>
> >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/516
> >>>>>>
> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
> >>>>>>
> >>>>>> I suggest that Eric shepherds this proposal.
> >>>>>>
> >>>>>> Please guide us to a conclusion as outlined in
> >>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Joachim
> >>>>>>
> >>>>>> --
> >>>>>> Joachim Breitner
> >>>>>>  mail at joachim-breitner.de
> >>>>>>  http://www.joachim-breitner.de/
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220919/c941c7dc/attachment.html>