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

[Bas van Dijk]

On 11 July 2012 23:45, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
>> On 11 July 2012 20:49, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>> I think the idea was to have Unsafe modules and move the unsafe functions
>>> there. :-)
>>
>> Indeed. I don't see the point about having .Safe modules. Modules
>> should be safe by default as you mentioned before. I guess the reason
>> we have .Safe modules in base and vector is for backwards
>> compatibility.
>>
>> The ideal, but currently, impossible way of dealing with this is to
>> mark the _export_ of unsafe functions in a module as DEPRECATED and in
>> a later version remove the unsafe functions and mark the module as
>> Trustworthy. However this requires support for deprecating exports:
>>
>> http://hackage.haskell.org/trac/ghc/ticket/4879
>
> 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.

Bas