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@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@joachim-breitner.de
  http://www.joachim-breitner.de/

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee