[GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates

[GHC]

#15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates
-------------------------------------+-------------------------------------
        Reporter:  ckoparkar         |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:  GHCProposal
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 Option (2) seems like the obvious choice (at first) -- but then we realize
 that doing it means that we have to really change a lot of syntax! In
 particular, incomplete record updates cannot be cleanly refactored.

 We also have another option:

 4. Refine GHC's types so that these warnings go away.

 For example, if we have

 {{{#!hs
 data T = MkT1 { foo :: Int } | MkT2 { bar :: Bool }
 }}}

 and have `t { foo = 5 }` somewhere, we'll get an error. But perhaps there
 is enough logic to suggest that `t` will always be a `MkT1`. We could
 refactor to

 {{{#!hs
 data T = MkT1 T1 | MkT2 T2
 data T1 = Mk1 { foo :: Int }
 data T2 = Mk2 { bar :: Bool }
 }}}

 and then our variable `t` would have type `T1` instead of `T` and all
 would be well.

 Of course, this refactoring introduces new memory allocations at runtime,
 and it may be hard to make all the types work out. It's thus impractical.
 However, it suggests a way forward here:

 Do (1), but make (4) the end goal. That is, just squash the warnings for
 now, but have it be an explicit goal (with a ticket to track the goal) to
 remove the squashings. This would mean, e.g., that we would need a way for
 the refactoring above ''not'' to take extra allocations at runtime. (This
 would be a huge improvement for Haskell overall!) And we'd likely need
 dependent types :). But all this would be very nice concrete fodder for
 why such improvements are called for.

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