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

Match semantics re. pattern order #1186

Open
alimpfard opened this issue Sep 16, 2022 · 4 comments
Open

Match semantics re. pattern order #1186

alimpfard opened this issue Sep 16, 2022 · 4 comments

Comments

@alimpfard
Copy link
Member

alimpfard commented Sep 16, 2022

Following from #1183 (comment)

Currently match patterns do not care about the order, as the patterns cannot be overlapping (aside from else, which is currently defined as "all cases not mentioned in the match"), so pattern order is ignored in enum matches.
Conversely, pattern order is significant in value matches, where we go down the list of values, checking for equality.

The first one allows matches like

match foo {
    else => x
    A => y
}

to yield y for A, which is dissimilar to other languages.

@robryanx
Copy link
Contributor

robryanx commented Sep 16, 2022

Was having a look at the c/c++ switch statement which does allow the default to be anywhere.
So similar to that it would make some sense to change the value matches.
We could also go the other way and enforce else being the last match to be more like if else.

@alimpfard
Copy link
Member Author

we can't really change the semantics of value matches unless we explicitly check for no overlaps, consider this:

let x = 1
match 1 {
    0..10 => "foo"
    1..3 => "foo, but not quite"
    (x) => "why"
    else => "else"
}

this is valid, none of the match arms are the same constant (though it might make sense to disallow), but there's no real way to do a full overlap check on these.

@robryanx
Copy link
Contributor

That seems okay, it can be that the order matters except for the else case that only matches if none of the other cases do.

@maddanio
Copy link
Contributor

else has to always be treated as the last branch, wether enforced to be written so or not. nothing can come after it, so not ordering it last does not make any sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants