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 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...

...

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@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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 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 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...

...

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@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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

+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 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...

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 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 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 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...

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@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

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I am sorry for the confusion — I misread the thread. Correction: +1 for the above amended proposal with -Wall so strengthened. That is all.

On 2022-09-19, at 09:38, Simon Peyton Jones wrote:

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 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 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...

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 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 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 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... > > 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@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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

And done Am Dienstag, dem 27.09.2022 um 21:13 -0400 schrieb Eric Seidel:

The feedback from the committee has been unanimously in favor, especially with the refinement to strengthen -Wall.

Joachim, I think we're good to merge.

On Mon, Sep 19, 2022, at 06:51, Chris Dornan wrote:

...

I am sorry for the confusion — I misread the thread. Correction: +1 for the above amended proposal with -Wall so strengthened. That is all.

...

On 2022-09-19, at 09:38, Simon Peyton Jones wrote:

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 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 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...

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 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 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 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... > > > > > > 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@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 > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee@haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/