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

[Edward Z. Yang]

+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
>