I'm in favour of accepting this proposal, with a couple of caveats that
I've raised on GitHub:

1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types*
but not *terms*. That makes it consistent with migrating to
`NoListTuplePuns`. Warnings should be actionable, and in this case the
action is to replace type-level occurrences of `[a]` with `List a`;
there is no action to take for term-level lists.

2. The specification does not currently seem very precise to me, and I
would ideally like to sharpen it up if we can come up with something
(see discussion at
https://github.com/ghc-proposals/ghc-proposals/pull/765/changes#r3641114009).
But I see this may be difficult, and I don't see this as a fundamental
blocker to the proposal.

Cheers,

Adam



On 20/07/2026 23:06, Matthías Páll Gissurarson wrote:
> I vote to accept as well. This will be very helpful in the future once
> dependent types land.
>
>   I agree with Simon though, getting a warning for `g :: [a]` or `h ::
> (a,b)`  would be very surprising for me without any extensions enabled.
>
> /Matti Palli
>
> On Mon, Jul 20, 2026 at 08:50 Sebastian Graf <sgraf1337@gmail.com
> <mailto:sgraf1337@gmail.com>> wrote:
>
>     I vote to accept the proposal.
>
>     It's just a warning and it seems like a useful future compat
>     mechanism where users avoid punning for more ergonomic dependently-
>     typed programs.
>
>     I explicitly vote to include list and puns in the scope as the flag
>     (as currently proposed). Otherwise, what is the point of the
>     warnings? Users who want to prepare for dependent types can just use
>     -XNoListTuplePuns, which they should be doing anyway.
>
>     Cheers,
>     Sebastian
>
>     Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones
>     <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>:
>
>         I'm generally OK with this proposal -- small benefits, but small
>         costs too.
>
>         I left some comments here. <https://github.com/ghc-proposals/
>         ghc-proposals/pull/765#issuecomment-4978364292>
>
>         Only one is substantial.
>
>           * Do we really want to include list and tuple puns in the
>             scope of the flag.  Using () and (a,b) and [a] as types is
>             so ubiquitous that few programs will compile warning free if
>             you switch on `-Wpun-occurrences`.
>           * Indeed, do we want to have `-Wpun-occurrences` at all.  I
>             argue against in my comment.
>
>         Simon
>
>
>
>         On Tue, 14 Jul 2026 at 22:28, Jakob Brünker
>         <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> wrote:
>
>             Hi all,
>
>             Our own Jaro Reinders, based on a proposal originally
>             by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-
>             Wpun-bindings`, to warn users when the same name appears in
>             the term namespace and type namespace:
>
>             https://github.com/ghc-proposals/ghc-proposals/blob/pun-
>             warnings/proposals/0000-pun-warnings.rst <https://
>             github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/
>             proposals/0000-pun-warnings.rst>
>
>             These warnings would not be enabled by default, but would
>             bring us a step forward on the path outlined by the accepted
>             proposal #378 (Support the design for dependent types,
>             https://github.com/ghc-proposals/ghc-proposals/pull/378
>             <https://github.com/ghc-proposals/ghc-proposals/pull/378>),
>             by supporting writing code in a way that plays well with the
>             principles described in that proposal (i.e. the lexical
>             scoping principle and syntactic unification principle).
>
>             They are also a good match for the recently introduced `-
>             XNoListTuplePuns`, which already lets users avoid puns for
>             some builtin types. Any users of `-XNoListTuplePuns` will
>             likely want something along the lines of this proposal.
>
>             I left some comments on the github thread but I think they
>             are small enough that they don't have to prevent us from
>             voting on it.
>
>             I recommend we accept.
>
>             Please indicate whether you wish to accept this proposal.
>
>             Jakob
>
>             _______________________________________________
>             ghc-steering-committee mailing list -- ghc-steering-
>             committee@haskell.org <mailto:ghc-steering-
>             committee@haskell.org>
>             To unsubscribe send an email to ghc-steering-committee-
>             leave@haskell.org <mailto:ghc-steering-committee-
>             leave@haskell.org>
>
>         _______________________________________________
>         ghc-steering-committee mailing list -- ghc-steering-
>         committee@haskell.org <mailto:ghc-steering-committee@haskell.org>
>         To unsubscribe send an email to ghc-steering-committee-
>         leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
>
>     _______________________________________________
>     ghc-steering-committee mailing list -- ghc-steering-
>     committee@haskell.org <mailto:ghc-steering-committee@haskell.org>
>     To unsubscribe send an email to ghc-steering-committee-
>     leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
>
>
> _______________________________________________
> ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
> To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org