mtl current master is Safe-inferred (but actually may not be)

[phadej]

e.g. see the box on the right:

While PVP doesn't mention Safe Haskell explicitly, there was discussion about it https://github.com/haskell/pvp/issues/22

Dropping Safe Haskell support is fine in major bump, but it will cause some friction. Some of (direct) reverse dependencies are expecting mtl to be Safe Haskell (e.g. @ekmett libs).

I noticed that some new stuff might use DerivingVia. I think it was allowed in Safe modules until very recently (ghc-9.2.2 or 9.4? because GeneralizedNewtypeDeriving is unsafe, so is DerivingVia), so safedness may change if not stated explicitly. mtl being explicitly Trustworthy would be fine, I guess.

[ekmett]

Yet another safe-haskell footgun.. and folks wonder why I stopped even bothering to try to handle it.

The only way I know to safely handle safe haskell is to explicitly mark a module as Trustworthy and then forcibly import a module marked Unsafe.

That is literally the only way to get into a known state.

Everything else leads to errors and warnings as upstream packages change their trustworthiness level. It also seems directly contra the intent of the feature and risks masking any transitive leaks of unsafety.

[phadej]

The only way I know to safely handle safe haskell is to explicitly mark a module as Trustworthy and then forcibly import a module marked Unsafe.

It's not the only way.

GHC-9 has -Winferred-safe-imports warning, so you can mark your modules as Safe and see if you get that warning and complain to the upstream. (EDIT: there is also -Wmissing-safe-haskell-mode which is "you forgot a safety definition for your module")

That is what I did/used to the part of kmettverse up to free IIRC, it's all explicitly Safe (or Trustworthy if cannot do better)

So if this issue is not fixed, when free is updated to allow mtl-2.3, recent GHCs will complain.

[ekmett]

The problem with the 'see if you get the warning' is it varies strongly by build plan, and for the other, unplanned for build failures not blocked by version bounds are even worse. I still just want a "This module locally is at least Trustworthy and if you can infer it safe, do so and stop bothering me or all my users" flag. I've asked for it ever since safe haskell was introduced and just stopped screaming into the void, because nobody was listening.

[ekmett]

IIRC, the best approach I have at present is

if impl(ghc>=8.0)
    ghc-options: -Wno-trustworthy-safe

and then just putting Trustworthy wherever I want to mark the module itself as behaving as safe. This is my best notion of "TrustworthyOrBetter".

I just keep forgetting this works, because it is such an asinine way to have to solve the problem.

[ekmett]

It also has the unfortunate side-effect of greatly enlarging the trusted codebase whenever I have to use it.

[phadej]

@ekmett

The problem with the 'see if you get the warning' is it varies strongly by build plan, and for the other, unplanned for build failures not blocked by version bounds are even worse. I

Again, the things up to free have the lower bounds of their dependencies (mostly) so high that said dependencies are using -Wmissing-safe-haskell-mode, or at least explicitly mention in the changelog that they are Safe / Trustworthy. E.g. https://hackage.haskell.org/package/comonad-5.0.8/changelog

5.0.8 [2020.12.30]

• Explicitly mark modules as Safe or Trustworthy.

I don't see this problem much different than having explicit type-signatures or not. Bindings (modules) can change types (safedness) if other things (modules) change types (safedness), it's a good practice to add type-annotations (safe/trustworthy/unsafe annotations). IMO having an explicit declaration everywhere is a way to forward. Safe-inferred was a mistake, the paper introducing it as ones who don't use, don't need to care is just wrong, as the experience shows.

mtl has been explicitly safe since long enough, and I hope this doesn't change.

[ekmett]

I hear you. I'm probably just grumbly that given DerivingVia's recent change in status I expect I'm going to be rejiggering a lot of these annotations on any decently fresh code I've written, yet again, for all of the 2 users of SafeHaskell that exist.

[phadej]

@ekmett join the choir at https://gitlab.haskell.org/ghc/ghc/-/issues/19605 (or and other Safe Haskell + coerce issues.

But TBH, another direction is just abandon Safe Haskell, Data.Coerce is way too useful to not be used. The two Safe Haskell users could cry to GHC developers. (I haven't ever met any end-user).

[kozross]

Resolved by #111.