mtl current master is Safe-inferred (but actually may not be) about mtl HOT 9 CLOSED

@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.

from mtl.

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.

from mtl.

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.

from mtl.

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.

from mtl.

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.

from mtl.

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

from mtl.

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.

from mtl.

@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).

from mtl.

Resolved by #111.

from mtl.