On 30/08/2012 02:33, Johan Tibell wrote:
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.
+1 from me, although when we discussed doing this previously Roman was not keen.
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.
Why not a deprecation pragma initially? That's like adding another level of "soft deprecation"; how long before we also need "extra-soft deprecation" and "ultra-soft deprecation"? (I feel a bog-roll analogy coming on :-)
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
We also have: Data.Array.IO.Safe Control.Monad.ST.Safe Foreign.Marshal.Safe and I think all of these are in the same state: the unsafe APIs in the non-Safe modules are currently deprecated, and the .Safe modules can be removed at some time in the future. Cheers, Simon