Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wildcard pattern with guard in first position breaks exhaustiveness of pattern match #7278

Open
phagenlocher opened this issue Nov 30, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@phagenlocher
Copy link

The following function has an exhaustive pattern match which is correctly identified as such:

f : [A, B], U8 -> Bool
f = \x, y ->
    when x is
        A -> Bool.true
        B -> Bool.false
        _ if y > 1 -> Bool.false

Note that the wildcard does not make this pattern exhaustive. This is already covered by the cases A and B.

When the wildcard pattern is moved in between the A and B patterns, the following code is still fine:

f : [A, B], U8 -> Bool
f = \x, y ->
    when x is
        A -> Bool.true
        _ if y > 1 -> Bool.false
        B -> Bool.false

However, when making the the wildcard pattern the first pattern of the match roc check incorrectly reports this as an error:

── UNSAFE PATTERN in src/Test.roc ──────────────────────────────────────────────

This when does not cover all the possibilities:

5│>      when x is
6│>          _ if y > 1 -> Bool.false
7│>          A -> Bool.true
8│>          B -> Bool.false

Other possibilities include:

    _    (note the lack of an if clause)

I would have to crash if I saw one of those! Add branches for them!

────────────────────────────────────────────────────────────────────────────────

1 error and 0 warnings found in 42 ms
@phagenlocher phagenlocher changed the title Wildcard with if in first position breaks exhaustiveness of pattern match Wildcard pattern with guard in first position breaks exhaustiveness of pattern match Nov 30, 2024
@Anton-4 Anton-4 added the bug Something isn't working label Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants