Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not address Safe Haskell related breakage #22

Open
snoyberg opened this issue Feb 5, 2018 · 4 comments
Open

Does not address Safe Haskell related breakage #22

snoyberg opened this issue Feb 5, 2018 · 4 comments

Comments

@snoyberg
Copy link

snoyberg commented Feb 5, 2018

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
Copy link
Collaborator

phadej commented Feb 5, 2018

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
Copy link
Member

hvr commented Feb 5, 2018

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
Copy link
Author

snoyberg commented Feb 5, 2018

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.

hvr added a commit to haskell/mtl that referenced this issue Feb 24, 2018
This avoids relying on the fragile "safe-inferred" status
and thus gives `mtl` a more explicit SafeHaskell API contract.

C.f. haskell/pvp#22
@phadej
Copy link
Collaborator

phadej commented May 25, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants