#10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That's the right place. Currently we have {{{ -- Fail straight away for better error messages -- See Note [Use canEqFailure in canDecomposableTyConApp] | isDataFamilyTyCon tc1 || isDataFamilyTyCon tc2 = canEqFailure ev eq_rel ty1 ty2 | otherwise = canEqHardFailure ev eq_rel ty1 ty2 }}} I think you are proposing {{{ | eq_rel == ReprEq && not (isDistinctTyCon tc1 && isDictinctTyCon tc2) = canEqFailure ev eq_rel ty1 ty2 | otherwise = canEqHardFailure ev eq_rel ty1 ty2 }}} That looks right, given the comment on `isDistinctTyCon`: {{{ -- | 'isDistinctTyCon' is true of 'TyCon's that are equal only to -- themselves, even via coercions (except for unsafeCoerce). -- This excludes newtypes, type functions, type synonyms. -- It relates directly to the FC consistency story: -- If the axioms are consistent, -- and co : S tys ~ T tys, and S,T are "distinct" TyCons, -- then S=T. }}} Tihs comment is vague about roles. If we have a poof co :: S ~r T, and S and T are "distinct" then S=T. But at what role is 'r'? It would be helpful to clarify this comment in role vocabulary. Similarly the comment `Note [Pruning dead case alternatives]` in `Unify.hs` needs reviewing in the role world. `Unify.typesCantMatch` is basically checking for apartness; which is also implemented somehwere else. Can we combine? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10493#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler