Remove Safe Haskell pragmas

[langston-barrett]

I just ran into an issue like #139. {-# LANGUAGE Safe #-} annotations seem to cause mysterious and painful-to-debug build failures, and for relatively little benefit. Is there any reason to keep them?

Removing them would probably be considered a breaking change, and require a major version bump.

[RyanGlScott]

More concretely, you can reproduce the issue by running:

$ cabal repl -b parameterized-utils -w ghc-8.10 --constraint="parameterized-utils==2.1.6.0" --constraint="lens<5"
Warning: The package list for 'hackage.haskell.org' is 23 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - parameterized-utils-2.1.6.0 (lib) (requires build)
 - fake-package-0 (lib) (first run)
Starting     parameterized-utils-2.1.6.0 (lib)
Building     parameterized-utils-2.1.6.0 (lib)

Failed to build parameterized-utils-2.1.6.0.
Build log (
/home/rscott/.cabal/logs/ghc-8.10.7/parameterized-utils-2.1.6.0-13035a0aac0af162c9e2ac1bd20dbbf2b4de29c08648ef91d6a31e99488888b3.log
):
Configuring library for parameterized-utils-2.1.6.0..
Preprocessing library for parameterized-utils-2.1.6.0..
Building library for parameterized-utils-2.1.6.0..
[ 1 of 38] Compiling Data.Parameterized.Axiom
[ 2 of 38] Compiling Data.Parameterized.Compose
[ 3 of 38] Compiling Data.Parameterized.Classes
[ 4 of 38] Compiling Data.Parameterized.Ctx
[ 5 of 38] Compiling Data.Parameterized.Ctx.Proofs
[ 6 of 38] Compiling Data.Parameterized.DecidableEq
[ 7 of 38] Compiling Data.Parameterized.NatRepr.Internal
[ 8 of 38] Compiling Data.Parameterized.Nonce.Unsafe
[ 9 of 38] Compiling Data.Parameterized.TH.GADT
[10 of 38] Compiling Data.Parameterized.DataKind
[11 of 38] Compiling Data.Parameterized.TraversableFC
[12 of 38] Compiling Data.Parameterized.TraversableF
[13 of 38] Compiling Data.Parameterized.Some
[14 of 38] Compiling Data.Parameterized.SymbolRepr
[15 of 38] Compiling Data.Parameterized.Nonce
[16 of 38] Compiling Data.Parameterized.Nonce.Transformers
[17 of 38] Compiling Data.Parameterized.NatRepr
[18 of 38] Compiling Data.Parameterized.Fin
[19 of 38] Compiling Data.Parameterized.HashTable
[20 of 38] Compiling Data.Parameterized.ClassesC

src/Data/Parameterized/ClassesC.hs:32:1: error:
    Data.Parameterized.Some: Can't be safely imported!
    The module itself isn't safe.
   |
32 | import Data.Parameterized.Some (Some(..))
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: cabal: Failed to build parameterized-utils-2.1.6.0 (which is required
by fake-package-0). See the build log above for details.

In this example, the culprit is the Safe annotation in Data.Parameterized.Some, which clashes with the fact that Control.Lens is inferred as Unsafe (but only in pre-5 versions of lens!).

[RyanGlScott]

One alternative to removing the Safe annotations would be to replace them with Trustworthy instead, which would avoid breaking any downstream code that relies on importing things from parameterized-utils in a safe way. By default, GHC will warn you if you mark something as Trustworthy that could instead be Safe, but it is possible to suppress that warning.

[langston-barrett]

One alternative to removing the Safe annotations would be to replace them with Trustworthy instead, which would avoid breaking any downstream code that relies on importing things from parameterized-utils in a safe way.

This seems reasonable given that the only imports from lens in Some are

parameterized-utils/src/Data/Parameterized/Some.hs

Line 23 in 4ed9f5c

import Control.Lens (Lens', lens, (&), (^.), (.~))