[Feature Request] Can GHC report implicit constructor matches?
Motivation
In long running projects, it is common that a new constructor gets added to an existing data-type. The question then becomes what parts of the code we need to modify to support this new constructor. It would be great if there was a way for ghc (or ghci
) to report, for a given constructor, all locations where the program implicitly matches against it, i.e., the constructor gets matched against a wildcard.
This facility would greatly aid in code maintenance and refactoring tasks.
Proposal
Consider a data-type with lots of constructors:
data X = X1 | X2 | ... | Xn
we might have many places that only care for a few of these:
f X1 = rhs1
f X2 = rhs2
f _ = error "can't happen"
or
case expr of
X1 -> rhs1
X5 -> rhs2
_ -> error "can't happen"
If we now add a new constructor XK
that didn't exist before, we'd like GHC to tell us where in our code this constructor is implicitly matched; so we can review and decide if the "ignoring" behavior is OK, or we should add relevant code.
Obviously, this should work just the same if the constructor has arguments, matched in a nested way, etc. I imagine it might be a ghci command:
:implicit_match XK
or perhaps a ghc command-line option which spits out a report. The details aren't particularly important and if implemented, the implementors can choose the most appropriate design.
Objections
When these sorts of requests come, it is common for people to point out that this may not be possible in general. And indeed, I do not expect GHC to give a precise answer: It might report false positives (i.e., where the constructor wouldn't be matched, but it'd still be reported as such due to data-path considerations), or false negatives (i.e., the constructor would be matched, but the analysis gets fooled for some reason.)
And that's perfectly fine! Nobody is expecting for this analysis to be 100% accurate. Just like the current pattern-match warnings, the output of this command (in ghci), or analysis printed by ghc might be an over/under-approximation.
Just because the problem is unsolvable in general, doesn't mean the information GHC will provide will be useless; quite to the contrary, it'd go along way for code maintenance in both industrial and academic contexts. If necessary, the output of the command can have a disclaimer to the same effect.