
On 15 July 2012 14:53, Yitzchak Gale
On Sun, Jul 15, 2012 at 7:03 AM, Mark Lentczner
wrote: ...I went back and looked at Vector and now I see that there are large set of ".Safe" variants that are no more than re-exports of the exact same functions from the non .Safe versions of the modules with an extra safe haskell declaration added.... I think the state of affairs stinks. It will do nothing but confuse the heck out of users
Simon already pointed out that, in his opinion, the correct way to support SH would be:
- rename M to M.Internal (or suitable alternative) - rename M.Safe to M - add a (small) M.Unsafe where necessary
But that would break backwards compatibility for the unsafe parts of the API. It's up to the package maintainers whether or not they want to do that. If not, I would say revert to no Safe Haskell support and accept it in the platform. However, add a haddock comment something like this:
"Safe Haskell: If you do not use any functions in this module whose name contains the word 'unsafe', you can mark your module as 'Trustworthy'. Otherwise, please consult
."
To be fair, regardless of SH, I'd consider it good API design to put unsafe things into a separate module. I'd be interested to know what exactly the problem is with moving these functions into a separate module. If the only argument for not making this change is to avoid breaking the API then we should do it *before* including vector into the platform. P.S.: I really wish we had a tool like "gofix" that automates trivial API updates. That way simple API changes could be automated. There are tools like this for Java and C, too.