Maybe the answer should depend on whether the scrutinee has already been
forced. The new output ("We now say", below) offers up patterns that will
change the strictness behavior of the code. The old output did not.
Reading the link below, I see that, previously, there was an inconsistency with
-XEmptyCase, which *did* unroll one level of constructor. But maybe that made
sense because -XEmptyCase is strict (unlike normal case).
I'm just saying this because I think listing the constructors in the
-XEmptyCase case is a good practice, but otherwise I think they're
clutterful... and strictness is a perhaps more principled way of making this
distinction.
Richard
> On Nov 9, 2021, at 8:17 AM, Sebastian Graf <sgraf1...@gmail.com> wrote:
>
> Hi Devs,
>
> In https://gitlab.haskell.org/ghc/ghc/-/issues/20642
> <https://gitlab.haskell.org/ghc/ghc/-/issues/20642> we saw that GHC >= 8.10
> outputs pattern match warnings a little differently than it used to. Example
> from there:
>
> {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}
>
> foo :: [a] -> [a]
> foo [] = []
> foo xs = ys
> where
> (_, ys@(_:_)) = splitAt 0 xs
>
> main :: IO ()
> main = putStrLn $ foo $ "Hello, coverage checker!"
> Instead of saying
>
> ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]
> Pattern match(es) are non-exhaustive
> In a pattern binding: Patterns not matched: (_, [])
>
> We now say
>
> ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]
> Pattern match(es) are non-exhaustive
> In a pattern binding:
> Patterns of type ‘([a], [a])’ not matched:
> ([], [])
> ((_:_), [])
>
> E.g., newer versions do (one) case split on pattern variables that haven't
> even been scrutinised by the pattern match. That amounts to quantitatively
> more pattern suggestions and for each variable a list of constructors that
> could be matched on.
> The motivation for the change is outlined in
> https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110
> <https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110>, but I could
> easily be swayed not to do the case split. Which arguably is less surprising,
> as Andreas Abel points out.
>
> Considering the other examples from my post, which would you prefer?
>
> Cheers,
> Sebastian
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
