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. Cheers, Johan