dotnet / dotnet/fsharp

Improve Error Reporting: Unnecessarily vague pattern match warning

Open
#3,765 2 comments 0 reactions 0 assignees View on GitHub
Area-Compiler-PatternMatching Feature Improvement Impact-Medium Theme-Simple-F#
Dominant language
F#
Stars
4.3k
Forks
876
Avg merge
4d 11h
Merged PRs (30d)
131

Description

# What
Pattern matching provides an exhaustiveness warning if you fail to match against all cases. However, the match seems to be generalised as much as possible for e.g. tuples or records, even when it is clear that there is only a single case outstanding e.g given the following code:

```fsharp
type Colour = Red | Yellow
type Size = Big | Small

let describe thing =
match thing with
| Red, Big -> "Big and red"
| Red, Small -> "Small and red"
| Yellow, Big -> "Big and yellow"
```

we are given the following warning:

`warning FS0025: Incomplete pattern matches on this expression. For example, the value '(_,Small)' may indicate a case not covered by the pattern(s).`

In reality, there is only one case outstanding - `Yellow, Small`.

# Why
There are two reasons that this should be improved:

1. If there is only one outstanding value, it's easier to reason about if the compiler gave that case. This could also lead to a code refactoring to implement that case.
2. Leaving the `_` in may be confusing to newcomers. A concrete example would be easier to understand.

# How
I believe that the warning should be changed to *always* give a *fully concrete example* **where possible** e.g. numbers, strings, DU cases etc.. for all elements in a Tuple or Record.

Whilst we're at it, the wording could be slightly improved, with more guidance:

`
warning FS0025: The pattern match over this expression cannot be proved to account for all cases. For example, the value '(Yellow, Small)' may indicate a case not covered. You should account for all cases either by adding extra patterns for each case, or through the use of the _ (wildcard) pattern. Leaving unhandled cases in a pattern match can lead to runtime errors, and is not recommended.
`

I know that this is more verbose, but adding the explanation at the end will again provide a bit of guidance to new developers as well as explaining the risks of not doing it.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.