[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