Indeed!  That seems to be a direct violation of this language in the manual:

"An important part of this is that safe compiled code is not able to examine or create data values using data constructors that it cannot import"

And the funny part is that that is unrelated to my particular problem of the user making their own Generic instances and is instead related to simply exposing "to"...

Thanks for putting that together.

On Mon, Oct 7, 2013 at 1:13 AM, John Lato <jwlato@gmail.com> wrote:
On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton <rrnewton@gmail.com> wrote:

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam <ganesh@earth.li> wrote:
 - Referential transparency: e.g. no unsafePerformIO
 - Module boundary control: no abstraction violation like Template
Haskell and GeneralizedNewtypeDeriving
 - Semantic consistency: importing a safe module can't change existing
code, so no OverlappingInstances and the like
Is this change necessary to preserve the existing properties, or are you
hoping to add a new one?

I'm not currently aware of ways to break these invariants *just* with GHC.Generics.  Hmm, but I would like to know why it is marked trustworthy and not inferred-safe...

I'm really not a safe haskell expert, but I believe this is a demonstration of using GHC.Generics to violate a module's abstraction boundaries with SafeHaskell enabled.

If I'm incorrect, I would appreciate if somebody could explain my error.  If, however, I'm correct, then I think that Ryan's proposal of marking GHC.Generics Unsafe is the best way to remedy the problem.

A possible stumbling block may involve base and package-trust, but I'm not certain of the current status.

John L.