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>:
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> 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/0...
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), 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 To unsubscribe send an email to 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