Does not address Safe Haskell related breakage

[snoyberg]

In haskell/parsec#88, the fact that a module from the parsec package is no longer inferred safe (according to Safe Haskell) means that a downstream package, MissingH, was broken by a minor version bump. From what I can tell, this form of breaking change is not currently covered by the PVP. Is this something worth adding?

[phadej]

I think we should have mention of Safe Haskell in PVP:

Experience shows that you shouldn't depend on module safety of modules which aren't explicitly marked Safe or Trustworthy, because there aren't tools for package authors to maintain "safety" property.

OTOH changing the explicit module safety should be considered breaking change.

Good help would be a GHC flag which would warn when your explicitly tagged Safe module depends on Safe (inferred) modules.

Related: ekmett/semigroupoids#69

[hvr]

To add to @phadej's comment: this has been a constant annoyance with SafeHaskell over the years; automatically inferred safety is too fragile to rely upon, as it tends to depend on several input parameters which cannot be controlled in a principled way by the consumer of a package (which as such breaks a fundamental invariant the PVP paradigm is build upon). As such, I concur, that every package that depends on a non-explicitly declared safety property is in violation, as the safety property wasn't announced as part of the API contract and is, at best, an accidental feature.

I've got a related pet-peeve of my own to contribute: haskell-hvr/rss#7

[snoyberg]

Agreed with all comments here; some kind of tooling support to avoid accidentally depending on implicit Safe Haskell and then indicating in the PVP that this kind of dependence is not reliable is a great idea.

[phadej]

FYI GHC-8.10.1 has -Wwarn=inferred-safe-imports flag. (It's not part of -Wall).