As the Mighty Morphin' Power Rangers say: "Let's do this!" - Mark

+1 Cheers, Edward Excerpts from Johan Tibell's message of Wed Aug 29 21:33:44 -0400 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.

Cheers, Johan

Hi,

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. Milan

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

On 30/08/12 03:33, Johan Tibell wrote:

* 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.

Is there a particular reason for first deprecating the functions exported from Data.Vector, instead of just removing them from their original location? By removing the Data.Vector.Safe module you already break some existing code, with the easy fix of moving to import Data.Vector. Moving the the unsafe functions to Data.Vector.Unsafe would introduce similar breakage, with a similarly easy fix of adding an import declaration. Twan