On 11 July 2012 23:45, Johan Tibell <johan.tib...@gmail.com> wrote: > On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk <v.dijk....@gmail.com> wrote: >> On 11 July 2012 20:49, Henning Thielemann <lemm...@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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
