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, most
of 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 want
is really `-Wcompat-error`, or we rather change the notion of -Wcompat to also promote warnings to errors early? In any case either the
current 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 report
back regressions, bugs, ... early on during alphas, betas, and release candidates. Right now I can't. I usually have to wait for x.y.4+. That
also means the feedback for anyone working on GHC is terrible. You won't hear about bugs until late in the release cycle where the
master branch has moved forward by a lot. At the same time it's painful for integrators who end up having to backport and patch old
Our current production compiler is 8.10, we could not switch to 9.2 due to performance regressions. And finally have almost everything
compiling 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 something
I'd absolutely support!
Best,
Moritz