safe vs. unsafe (Was: Haskell Platform proposal: Add the vector package)

[Johan Tibell]

On Wed, Jul 11, 2012 at 3:08 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
>> But why? The number of people who will benefit from this mass
>> deprecation/mass migration is tiny.
>
> While I agree that the number of people who will benefit is tiny I
> don't think it's a "mass" deprecation. In base there are only 7
> functions that need to be deprecated:
>
> * Control.Monad.ST.Lazy.unsafeInterleaveST
> * Control.Monad.ST.Lazy.unsafeIOToST
>
> * Control.Monad.ST.unsafeInterleaveST
> * Control.Monad.ST.unsafeIOToST
> * Control.Monad.ST.unsafeSTToIO
>
> * Foreign.ForeignPtr.unsafeForeignPtrToPtr
>
> * Foreign.Marshal.unsafeLocalState
>
> And because of their unsafe nature are probably not used a lot, so the
> impact would not be big.
>
> However, I do think it's important to have the ability to first
> DEPRECATE the exports so users are warned well in advanced that they
> have to change their code.

I'm sorry but I no longer know what you're talking about. What Simon
is arguing for is that functions that are unsafe be moved to their own
module (e.g. .Unsafe). Slightly simplified, a function is unsafe
(according to SH) if

 * it's one of the "basic" unsafe functions (e.g. unsafePerformIO), or
 * it calls one of these functions.

For example, most functions in bytestring are unsafe because their
implementation uses unsafePerformIO. To be very concrete, if 'map' on
ByteStrings is unsafe it needs to be moved from

    Data.ByteString

to

    Data.ByteString.Unsafe

In order to do so we need to deprecate the 'map' version in
Data.ByteString in order to give users a chance to upgrade their code.

Do you now see why loads of functions need to be deprecated?

-- Johan