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

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


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



More information about the Libraries mailing list