Trustworthy is still nearly unusable
8310 still causes me pretty much constant agony as a developer.
Despite the old issue being closed, I really do not consider this issue fixed. Rather than perform thread necromancy, I am posting this as a fresh issue.
When my upstream packages become more safe, my users get more warnings, not less.
This yields terribly perverse incentives.
If I ever want to say in a package that I know that this module is Safe
for users to use because it exposes a safe API, I'm stuck hoist upon the horns of a dilemma.
-
If I enable
-Winferred-safe-imports
, which is your only way to get any decent feedback about upstream safety improvements, and import a third-party library that is currently only inferred safe, then I can no longer claim to beSafe
, but worse, I can't even claim to beTrustworthy
, because users will get warned that I could do better, because I'm inferredSafe
. -
If I leave off the annotation then I merely punt the issue downstream, because now any users of mine will get the same warnings, because now they are importing me and i'm merely inferred safe, or possibly
Unsafe
, who knows, because I sure won't know, until I get a bug report and have to track down the fact that someone somewhere depended onData.Coerce
to avoid eta-expanding a function somewhere.
Example:
If I incur a dependency on Data.Sequence
, which is merely inferred-safe, then my only recourse is to import an Unsafe
module myself and forcibly downgrade myself to Trustworthy
. This forces me into the trusted code base, even if I could have been treated as Safe
.
All I really want some way to say that a module is TrustworthyOrBetter
. The current semantics of Trustworthy
are to yell at the user if the security situation is better than they expect. Right now the only way I have to resolve this is terrible, and always forces every module that depends on an inferred-safe module into the trusted code base, whether it needs to be there or not.
{-# Language Unsafe #-}
module TrustworthyOrBetter () where
{-# Language Trustworthy #-}
{-# options_ghc -Winferred-safe-imports -Wmissing-safe-haskell-mode #-}
module Data.Machine.Mealy where
import Data.Sequence -- is merely inferred safe
import TrustworthyOrBetter () -- Unsafe
The previous issue was closed mostly on the grounds that:
It becomes unintuitive what packages you'll need to trust and that set will change unpredictably over time.
That remains the case. Except now it affects every single library author, not just the rare user that actually plans to use SafeHaskell
on their IRC bot or Haskell web service.
I generally can't let my modules infer as Safe
, which was my old solution, when I mostly gave up on SafeHaskell correctness years ago and just took to accepting patches that maintain it, because then I clobber anyone using these warnings, and I really don't want to force every single module in almost every library I maintain unnecessarily into the trusted code base, just to sate a warning that the situation is too good.
I can't even just not use the extension, because it is just not an option if I want folks to be able to continue to use my libraries on IRC bots and the like.
In the meantime, I'm stuck with solutions like that shown above, which nearly completely destroy the benefit and intent of SafeHaskell.