[ghc-steering-committee] Warnings

Moritz Angermann moritz.angermann at gmail.com
Mon Sep 25 09:25:10 UTC 2023


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 at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230925/b81cd1b1/attachment.html>


More information about the ghc-steering-committee mailing list