Removing the .Safe modules from vector (was: Haskell Platform proposal: Add the vector package)

Johan Tibell johan.tibell at
Thu Aug 30 03:33:44 CEST 2012

Hi all,

After reading the Safe Haskell paper today, I got the impression that
no one actually wants the .Safe modules currently in vector. If vector
was to be made Safe Haskell friendly, we should instead add .Unsafe
modules (and have the rest of the modules declared Trustworthy).
Having .Unsafe modules is better than having .Safe modules, because

 * there are many more safe functions than unsafe functions, and
 * Haskell is by default safe, so having modules called .Safe is a bit
like having modules called .Pure. There's precedence for having
.Unsafe modules in e.g. bytestring.

If that's the case, and if Roman agrees, I suggest we release a new
major version that

 * removes all the .Safe modules [1],
 * adds new .Unsafe modules, and
 * marks the functions that are now exported through the .Unsafe
modules deprecated in their original (non-.Unsafe) location.

I suggest that the deprecation doesn't involve an actual deprecation
pragma in this release [2], but instead just a comment. A future major
release could add the deprecation pragma and another major release
after that could remove the actual functions.

Actually removing functions causes huge Hackage churn so I suggest
that we don't do that until the new .Unsafe modules have been around
for a long time.

1. Normally I would suggest a deprecation period before removing
functions from an API, but I just searched through all of Hackage and
there's only a single package (bitvec) that makes use of the .Safe API

2. While deprecation pragmas sound good in theory there isn't much
library authors can do to make the warning go away. An author can
migrate to the new API, but in practice authors need to support a
couple of releases of each library.


More information about the Libraries mailing list