<div dir="ltr">Joachim,<div><br></div><div>> the main driving motivation is that we really want libraries to stop building if their dependencies have introduced new methods.</div><div><br></div><div>So we want this because we introduce extra fields in a dependency and thus "silently" break all consumers? Not because</div><div>people write new green-field code and end up ignoring the warning? And even worse because you can transitively depend</div><div>on a library that was broken by one of its dependencies adding fields? This case was not clear to me from the proposal.</div><div>Wouldn't this be something that PVP should guard against? Adding new fields should result in a new major version, because</div><div>it's technically a breaking change?</div><div><br></div><div>I think this is more of an education/communication problem.  The existing warnings do not seem to convey this insight very</div><div>well?</div><div><br></div><div>From the PVP (<a href="https://pvp.haskell.org">https://pvp.haskell.org</a>):</div>> Breaking change. If any entity was removed, or the types of any entities or **the definitions of datatypes or classes were changed**, or orphan instances were added or any instances were removed, then the new A.B MUST be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra orphan instances to be exported and thus force a major version change.<div>(emphasis mine)</div><div><br></div><div>Cheers,</div><div>  Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Oct 2023 at 20:16, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:<br>
> By putting the new behaviour in GHC2024, users can choose when to<br>
> update their code to accommodate the change.<br>
<br>
almost. Users choose when to update _their_ code to a new language<br>
edition, but not when their dependencies are updated.<br>
<br>
For most proposals, I’d fully agree that going via a new language<br>
extension, possibly on by default in a future GHC20xx, is the way to<br>
go. But in this _particular_ case, we have that the main driving<br>
motivation is that we really want libraries to stop building if their<br>
dependencies have introduced new methods. These libraries are very<br>
likely not going to use GHC2024 any time soon: <br>
<br>
Firstly, because libraries can’t upgrade to new GHC20xx as quickly as<br>
programs can, because they want to support older versions of GHC.<br>
<br>
But secondly, because this quality control of “build fails when things<br>
are likely wrong” is especially important for less-actively maintained<br>
libraries.<br>
<br>
Changes tied to language pragmas only affect those modules/libraries<br>
that want to be affected. This is great in general, but not helpful for<br>
changes that need to apply to _all_ modules/libraries.<br>
<br>
So it seems that the present use case is only well addressed if `-<br>
Werror=missing-methods` becomes a default in a future GHC version<br>
_independent_ of the language model. The stability document has a<br>
provision vor this: <br>
<br>
> (GR2) We may break (GR1), but only with a compelling reason, and with<br>
> careful consideration of impact..<br>
<br>
<br>
I suggest we first focus on this question: Does the proposed change<br>
should fall under this exception and be rolled out (with deprecation)<br>
globally.<br>
If yes, we do that.<br>
If not, we can then ponder if this change is still useful as part of a<br>
future GHC20xx, or not worth the bother then.<br>
<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>