[GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong

GHC ghc-devs at haskell.org
Fri Mar 21 23:36:27 UTC 2014


#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


More information about the ghc-tickets mailing list