[ghc-steering-committee] Warnings

[Moritz Angermann]

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> 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
> > 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/20230925/2aead8c3/attachment.html>