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
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@haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.orghttps://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee