#13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: I believe this is expected behavior. You can only coerce from `V Par1` to `Par` if the [https://ghc.haskell.org/trac/ghc/wiki/Roles role] of `V1`'s argument is permissive enough (that is, it must have a representational or phantom role, not a nominal role). But currently, all arguments to a type family (such as `V`) are always assigned nominal roles. This solves problems like the [https://ghc.haskell.org/trac/ghc/wiki/Roles#Theproblemwewishtosolve original motivation for roles], but it does rule out scenarios like yours. FWIW, I've been advocating for role inference/the ability to give type families role annotations in #8177. I think a type family like: {{{#!hs type family Id a where Id a = a }}} should definitely be able to have a representational role for its argument. Not sure about `V`, though. I'll cc goldfire for his thoughts as well. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13083#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler