[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)

[Moritz Angermann]

Joachim,

> the main driving motivation is that we really want libraries to stop
building if their dependencies have introduced new methods.

So we want this because we introduce extra fields in a dependency and thus
"silently" break all consumers? Not because
people write new green-field code and end up ignoring the warning? And even
worse because you can transitively depend
on a library that was broken by one of its dependencies adding fields? This
case was not clear to me from the proposal.
Wouldn't this be something that PVP should guard against? Adding new fields
should result in a new major version, because
it's technically a breaking change?

I think this is more of an education/communication problem.  The existing
warnings do not seem to convey this insight very
well?

>From the PVP (https://pvp.haskell.org):
> 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.
(emphasis mine)

Cheers,
  Moritz

On Mon, 9 Oct 2023 at 20:16, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:
> > By putting the new behaviour in GHC2024, users can choose when to
> > update their code to accommodate the change.
>
> almost. Users choose when to update _their_ code to a new language
> edition, but not when their dependencies are updated.
>
> For most proposals, I’d fully agree that going via a new language
> extension, possibly on by default in a future GHC20xx, is the way to
> go. But in this _particular_ case, we have that the main driving
> motivation is that we really want libraries to stop building if their
> dependencies have introduced new methods. These libraries are very
> likely not going to use GHC2024 any time soon:
>
> Firstly, because libraries can’t upgrade to new GHC20xx as quickly as
> programs can, because they want to support older versions of GHC.
>
> But secondly, because this quality control of “build fails when things
> are likely wrong” is especially important for less-actively maintained
> libraries.
>
> Changes tied to language pragmas only affect those modules/libraries
> that want to be affected. This is great in general, but not helpful for
> changes that need to apply to _all_ modules/libraries.
>
> So it seems that the present use case is only well addressed if `-
> Werror=missing-methods` becomes a default in a future GHC version
> _independent_ of the language model. The stability document has a
> provision vor this:
>
> > (GR2) We may break (GR1), but only with a compelling reason, and with
> > careful consideration of impact..
>
>
> I suggest we first focus on this question: Does the proposed change
> should fall under this exception and be rolled out (with deprecation)
> globally.
> If yes, we do that.
> If not, we can then ponder if this change is still useful as part of a
> future GHC20xx, or not worth the bother then.
>
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20231009/89998ac4/attachment.html>