#8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by ekmett): Both the (A) and (C) solutions have bad cases. It comes down to picking a poison. In (C), picking `nominal` as the default role means the `GeneralizedNewtypeDeriving` basically goes away with GHC 7.8. You will be unable to use GND for anything unless every author above you in the chain puts role annotations in. Moreover, we'll be stuck writing them forever for every data type. It still closes the GND loopholes, but it does so by nuking the site from orbit. For (A), picking `representational` as the default role means that authors have to deal with unexpected encapsulation leaks. This required a half dozen annotations over `base`, and a couple in `containers`, maybe a dozen in `lens` and affects a relative minority of modules. Both scenarios are bad. Argument in favor of (A) is that many authors have already refactored to write their instances this way over the course of the last 2 release candidates, because we've been hammering home that they'll have to deal with it and that in the long term it is less work for everyone going forward, but it does mean that the folks who do care about `SafeHaskell` need to be conscious of the new language feature. I rather don't like the fact that (A) puts a new burden on people silently, but I ''really'' don't like that (C) requires literally everyone to annotate everything forever. We'd never stop paying that tax, and everyone who thought they were ready for 7.8 is back to the drawing board, and needs to start preparing for the release anew. Turning this around to try to find something productive here, I have two thoughts: 1.) One option might be to add a warning to any data type that doesn't export its constructors that has representational role. That isn't perfect. Some folks expose constructors in `other-modules` that they don't leak to to the end user in `exposed-modules`, but it'd be a start and covers for example, the cases in `containers`. 2.) Is there actually a `SafeHaskell` problem here at all? `coerce` itself isn't currently exposed in a `Safe` module, so it can't be used for a `SafeHaskell` exploit directly without trust. I am currently unaware of any path by which we can abuse GND alone to obtain a coercion. If (2) holds, then while it is annoying to library authors that there is a new avenue to deal with that can violate their encapsulation, it does come into user-land from the same `GHC.Prim` module that you get `unsafeCoerce#` from, which can do everything `coerce` can do. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8827#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler