[GHC] #15584: nonVoid is too conservative w.r.t. strict argument types

[GHC]

#15584: nonVoid is too conservative w.r.t. strict argument types
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.5
      Resolution:                    |             Keywords:
                                     |  PatternMatchWarnings
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect         |  Unknown/Multiple
  error/warning at compile-time      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15305            |  Differential Rev(s):  Phab:D5116
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:2 dfeuer]:
 > Users need to be able to predict, reasonably reliably, how far they
 should go in explaining totality to the compiler.

 I agree! This proposed change would make it easier for users' to predict
 when a function is total. The rule is this: if it is possible to pass a
 well typed argument to a function //that doesn't bottom when demanded//,
 then that function must match that argument in order to be considered
 total. (The part in italics is what is new in GHC 8.8 after #15305, and
 further improved upon in this ticket.)

 > We certainly wouldn't want GHC to complain about a redundant pattern
 match in
 >
 > {{{#!hs
 > f :: S -> a
 > f (MkS (MkV v)) = absurd v
 > }}}
 >
 > because that's perfectly reasonable code.

 I would disagree about this being perfectly reasonable code—there's no
 reason to ever match on `MkS` (or `MkV`), since that is guaranteed to
 bottom when demanded. In other words, it's another form of unreachable
 code, since calling `f (MkS (MkV ⊥))` will bottom out before `MkV` (or
 `MkS`) are ever reached.

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