Hi Simon, I'm strongly in favour of the deprecation cycle (can we even backport the warning to patch releases?). I'm not sure we need a GHC proposal for this? Would this mean we need a proposal for every bug fix down the line? My view is as follows: I do not believe anyone exploits this bug _on purpose_. And breaking their code suddenly because, they overlooked a necessity no one informed them about, seems hostile to users, warning them and letting them know that this lack of declaration will be rejected in the future seems the right approach to me. If we can warn them even earlier (with older patch releases, the better). Cheers, Moritz On Mon, 25 Sept 2023 at 17:03, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Dear GHC SC
You may or may not have been following GHC ticket #22141 https://gitlab.haskell.org/ghc/ghc/-/issues/22141, and Ryan's merge request !11314 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314 .
The story is this:
- There is a bug in GHC that allows programs to use DataKinds without the -XDataKinds extension. - The MR fixes the bug. - But of course that will mean that some programs that previously compiled (exploiting the bug) will now fail to compile (correctly).
It seems like an example of our (GR2) discussion, but with a very different flavour than the (3+4=8) example.
Personally I think we should do it -- with a deprecation cycle saying "You need DataKinds for this program, and you don't have it on, but you will need it in the next release". I don't want us to grandfather bugs into GHC indefinitely -- although you could argue that the status quo does little harm, I suppose.
Any views? We will have some idea of the impact on head.hackage shortly.
*And specifically: do you want a GHC proposal for this change?*
Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee