[ghc-steering-committee] Warnings

[Eric Seidel]

I agree with Moritz that a GHC Proposal is not necessary. Proposals should be used for changes in *intended* user-facing behavior, this is just a routine bugfix. 

I also agree that a warning/deprecation period would be good, but I wouldn't spend overly on it. This sounds like a very easy issue to work around, just enable the extension explicitly. (Or would that have potential second-order consequences?)

On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones 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