I'm broadly in favour of accepting the proposal. I realise the history is complex here, so I don't think we should ask anyone to rewrite things further, though in general it would be nicer to have separate proposals for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the changes to imports (which as Joachim points out raise issues). I'm a bit concerned that the proposal does not motivate or specify -Wpattern-namespace-qualified very well. On 08/12/2022 08:33, Joachim Breitner wrote:
...
This gives us (at least) these options:
1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow.
Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions.
I would prefer a variant of 1: allow "data" as a keyword in import lists under ExplicitNamespaces, but make the other changes under other extensions. As I've said previously, I have a general preference for multiple small, orthogonal extensions rather than changing existing extensions to add unrelated features that happen to be in similar territory. I realise this is controversial, of course. Cheers, Adam -- 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