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

Bas van Dijk v.dijk.bas at
Thu Jul 12 00:08:29 CEST 2012

On 11 July 2012 23:45, Johan Tibell <johan.tibell at> wrote:
> On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk <v.dijk.bas at> wrote:
>> On 11 July 2012 20:49, Henning Thielemann <lemming at> 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:
> 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.


More information about the Libraries mailing list