[GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)

[GHC]

#15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler (Type    |              Version:  8.5
  checker)                           |             Keywords:
      Resolution:                    |  QuantifiedConstraints
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 If the constraint solver was ever faced with
 {{{
 [W] CTuple3 (Functor (WrappedF ty))
             (Foldable (WrappedF ty))
             (Traversable (WrappedF ty)
 }}}
 it'd probably work (although note the tricky overlap with the top level
 instance).  But will the derived instance give rise to that wanted
 constraint?  I think not.

 For built-in tuples, I think the constraint solver probably does just
 decompose them eagerly, rather than look for local instances of tuples.
 That is special behaviour, I grant you, but I have yet to see a case in
 which that's not the right thing to do.  Where are these strange wanted
 constraints going to come from?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15334#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler