Is the general consensus on this thread that defaults should never change, even if better defaults are discovered?On Tue, 19 Sept 2023 at 17:13, Chris Dornan <chris@chrisdornan.com> wrote:My opposition is entirely grounded in the change of default behaviour; otherwise i am in favour._______________________________________________On Tue, 19 Sep 2023 at 15:31, Simon Marlow <marlowsd@gmail.com> wrote:On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:I think that the motivation for this proposal is to make it harder to shoot yourself in the foot.Maybe implementing this "severe" category, but not changing its default to error, would get us some of the way there? Then "best-practice guidance" could be "use -Werror=severe", and job done. That's a bit easier to say than saying "use -Werrror=missing-methods -Werror= ..." etc.Absolutely! I'm only objecting to changing the default. Adding the "severe" category by itself is useful, I agree.CheersSimonSimonOn Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris@chrisdornan.com> wrote:Like Simon M I habitually develop with -Wall -Werror, and like Moritz I think we really need to be very careful about deliberately breaking packages._______________________________________________For sure, if we were starting anew I would be be sympathetic to treating them as errors, but, for me, that isn't a good enough reason to make this breaking change.For this reason I vote against this proposal.ChrisOn 19 Sep 2023, at 14:20, Simon Marlow <marlowsd@gmail.com> wrote:For those not aware, Hackage right now rejects packages with `-Wall -Werror` in their ghc-options because warnings change between GHC versions so this tends to lead to unnecessary breakage. I think that's a good policy, even though I use `-Wall -Werror` everywhere when developing.Interestingly, this proposal creates exactly the same kind of risk, by making some existing warnings errors by default and introducing the possibility that the set of warnings treated this way might change in the future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still a risk for developers.Also note that `ghc -XHaskell2010` will reject some legal Haskell2010 programs, unless you also say `-Wwarn=severe`. We are normally careful to document the ways in which GHC deviates from the language definition in the user guide.I can see the motivation, but I have to vote against here. I don't think we should change the set of programs accepted by the compiler unless absolutely necessary. If it's legal code today, it should be accepted by future versions of the compiler unless we have a really good reason to change that.CheersSimon_______________________________________________On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <moritz.angermann@gmail.com> wrote:Just to clarify: I am not against change, or evolution. I'm actually looking forward to progress. What I am against ist sudden breakage.As such, if there _is_ breakage (clc stackage is a subset), we have to assume there will be breakage in production codebases, mostof which are likely not public.Can't we have `-Wcompat` enable `-Werror=missing-methods`, and `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)Advertise this prominently in the release notes for GHC 9.10? And then enable this fully in GHC 9.14? Though I guess the flag we wantis really `-Wcompat-error`, or we rather change the notion of -Wcompat to also promote warnings to errors early? In any case either thecurrent documentation for -Wcompat would need to be adjusted, or we'd need something that signals new errors.Ideally I'd like to see something like a warning for `missing-methods`, with an additional note that this will become an error in GHC X.Y,and that one can opt into this behaviour by enabling -Wcompat.My test for support is generally: can I take existing code unmodified, swap out the compiler, and it will still compile? That way I can reportback regressions, bugs, ... early on during alphas, betas, and release candidates. Right now I can't. I usually have to wait for x.y.4+. Thatalso means the feedback for anyone working on GHC is terrible. You won't hear about bugs until late in the release cycle where themaster branch has moved forward by a lot. At the same time it's painful for integrators who end up having to backport and patch oldbranches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already states anything but 9.4 and 9.6 won't see any further releases.Our current production compiler is 8.10, we could not switch to 9.2 due to performance regressions. And finally have almost everythingcompiling with 9.6, but are far from having any form of performance profile feedback on 9.6 yet.Again, I'm not against breakage per-se. I'm against sudden breakage. Managed evolution or however we want to call it, is somethingI'd absolutely support!Best,Moritz_______________________________________________On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam@well-typed.com> wrote:On 18/09/2023 20:28, Richard Eisenberg wrote:
>
> Bottom line for me: I think we should implement and then experiment.
> Given the potentially delicate nature of this, I might even advocate for
> implementing this in a release branch, so that as much of Hackage as
> possible actually has a hope of compiling. Then test to see where the
> breakage occurs. If were happy with the result, rebase the
> implementation on master. But I don't want us to get into a state where
> we accept, implement, observe moderate breakage, and then blast ahead
> because the committee approved the idea.
The breakage concern is worth thinking about, I agree, but fortunately
in this instance we don't need to wait for an implementation to run an
experiment. The change can be relatively effectively simulated by
compiling with -Werror=missing-methods -Werror=missing-fields, and
indeed Oleg has done so already for clc-stackage as he reports here:
https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
Out of nearly 3000 packages, he found 22 were broken by
-Werror=missing-methods and 9 by -Werror=missing-fields.
Adam
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________
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.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.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