[ghc-steering-committee] Warnings

[Chris Dornan]

Indeed a bugfix with deprecation cycle seems entirely right.

> On 25 Sep 2023, at 14:30, Richard Eisenberg <lists at richarde.dev> wrote:
> 
> Yes, let's fix the bug with a deprecation cycle.
> 
>> On Sep 25, 2023, at 8:43 AM, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> 
>> I actually think a warning/deprecation period should be down in this case. It doesn’t break code right now. It is not critical for this to be fixed immediately (nothing significantly averse will happen to someone accidentally using this).
>> 
>> I’m willing to put some of IOGs resources at helping with implementing the deprecation warnings; leading by example, hoping this will inspire others to do the same in the future. 
>> 
>> Best,
>>  Moritz
>> 
>> On Mon, 25 Sep 2023 at 7:49 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>>> 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 <mailto:ghc-steering-committee at haskell.org>
>>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> 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/20230926/673ba10c/attachment.html>