We need to add role annotations for 7.8

[David Terei]

Adding in GHC-DEV. Yes, sorry for no contact, my GHC email filter was
misconfigured so only got alerted when SPJ emailed me directly a few
days back.


On 18 March 2014 17:36, David Mazieres expires 2014-06-16 PDT
<mazieres-i58umkudjfnfpfdx6jbbn3ymzi at temporary-address.scs.stanford.edu>
wrote:
> At Fri, 14 Mar 2014 18:45:16 +0100,
> Mikhail Glushenkov wrote:
>>
>> Hi Richard,
>>
>> > The real trouble with making this decision is that we have no real
>> > guidance. We've tried contacting David Terei (the originator of
>> > Safe Haskell) several times to no avail. If you are an actual
>> > consumer of Safe Haskell and would like to share your opinion on
>> > this front, I do encourage you to make a ticket, essentially
>> > requesting a resurrection of the extra Safe checks.
>>
>> Yes, it would be nice if David Terei or David Mazières (CC:ed) could comment.
>
> Sadly, it appears some mail may not have made it through to David
> Terei's mailbox.
>
> At any rate, David and I just discussed the new Coerce typeclass.
> Based on David's understanding of its behavior, it sounds pretty
> dangerous for Safe Haskell.  At a minimum, the programmer is going to
> need to understand a lot more than Haskell 2010 to write secure code.
>
> Based on my possibly limited understanding of the new
> feature--automatically generating instances of the Coerce type seems
> very un-Haskell-like.  By analogy, we could automatically generate
> instance of Read and Show (or add equivalent DebugRead/DebugShow
> classes) wherever possible, but this would similarly break abstraction
> by providing effective access to non-exported constructors.
>
> I understand why there is a need for something better than
> GeneralizedNewtypeDeriving.  However, implementing Coerce as a
> typeclass has the very serious disadvantage that there is no Haskell
> mechanism for controlling instance exports.  And if we are going to
> add a new mechanism (roles) to control such exports, exporting an
> instance that is never requested and that undermines modularity and
> abstraction is an unfortunate default.
>
> It may be too late for this, but a cleaner solution more in keeping
> with other extensions would be to have a -XDeriveCoerce extension that
> allows Coerce to be explicitly derived when safe.  This could be
> combined with leaving the previous behavior of
> GeneralizedNewtypeDeriving and just deprecating the language feature.
>
> Though controlling instance exports does not have a precedent, another
> option might be to special-case the Coerce class and only export
> instances of Coerce when all constructors of a type are also exported.
> This would prevent anyone from using Coerce to do things they couldn't
> already do manually.
>
> David
>