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.

Sign up for GitHub

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

Jump to bottom

RFC: Add match/in statements #2144

Closed
wants to merge 5 commits into from
Closed

RFC: Add match/in statements #2144

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
d61d1f2
inital RFC commit
Jul 27, 2017
73e34ec
Inital commit for the overlapping_match rfc
Nokel81 Sep 10, 2017
daf503d
Rewriting some of the parts and adding another example of a use
Nokel81 Sep 11, 2017
8f064a9
Changing the syntax over to "match fallthrough"
Nokel81 Sep 11, 2017
dee68cc
Changing the text to `match many` since fallthrough would imply usage…
Nokel81 Sep 11, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 15 additions & 14 deletions text/0000-overlapping_match.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,12 +31,12 @@ checked for exhaustiveness, be executed if more than one of them match the value

Basic Syntax:
```rust
match val in {
match fallthrough val {
pat | pat => expr,
pat => expr
}

match val in {
match fallthrough val {
pat | pat => expr,
pat => expr
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This deviation from the _ => ... syntax used by "regular" match is a bit unfortunate

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be a bit unfortunate but if you consider the meaning of _ it makes sense. The _ pattern means to match everything.

Expand All @@ -45,23 +45,24 @@ match val in {
```

Benefits of this syntax:
1. No new keywords need to be used. This is good thing since it means for a relatively small
addition there would be no code breaks of existing code with this change.
2. The `in` seems to imply that it sort of like an "iterator" of statements and will go through
each of them in turn.
1. Even though a new keyword has been made it will not break any code because Rust is a context
sensitive language. And adding such a keyword increases the perceptual area of the new syntax
so as to make it clear which type of match is being used.
2. The word `fallthrough` is used because it implies that after a branch is finished then the
control falls through to the check of the next branch.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Semantically, I consider this a big addition - which is why I'd like a more visible syntactic difference where this RFC to be accepted. Therefore, I consider the slight variation in syntax to be a downside. I expand on this further down.

Instead of in, I'd recommend using a terminal that more clearly indicates that this is top-down and more crucially that multiple branches may be taken. Perhaps the syntax might be: match inclusive <expr> { <patterns> }, or match topdown <expr> { <patterns> }.

  1. I don't agree that in implies this nearly strong enough for this to be instantly understandable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is fair and I am pretty sure that adding an additional keyword here wouldn't break any code since if a variable was called what ever it was that would be able to be checked but that is definitely something to consider

Copy link
Contributor

@Centril Centril Sep 11, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, adding the additional "keyword" should work w/o backwards incompatibility since there's no (iirc) parsing rule "<expr> <expr>".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a correct DFA adding that state would be rather complicated but I agree is do able

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... DFA for what? Lexing? The language is not regular...
Do note that parsing Rust is already at least context sensitive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have not actually looked that deep into Rust I didn't consider it to be that high order, though tbh I don't know why

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust's lexical grammar is already context-sensitive due to r##"strings like this"##. The actual grammar after tokenization makes do with a fixed lookahead (I forgot how much exactly, something in the order of 5 tokens or so).

Not a single real programming language is regular (not counting assembly and machine code). Fun fact: Even the simple-looking Lua grammar requires infinite lookahead to parse and is thus harder to parse than Rust.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More details here: https://stackoverflow.com/a/43693150/1063961 and here https://stackoverflow.com/a/43693194/1063961

Copy link
Contributor

@Centril Centril Sep 11, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think fallthrough implies that it will execute the statements / yield the expressions of the next match arm irrespective of whether the it's pattern holds or not, i.e: readers will expect C++ style switch behavior.

Instead I'd like to add match many to the 🚲 🏠

Meaning of parts:
1. The `else` is used in a similar sort of vein to that of the `_` pattern in normal matches.
The expression enclosed within this is only executed if none of the patterns within the
`match/in` expression are matched. If `else` and `_` are both present then the code within the
`match/fallthrough` expression are matched. If `else` and `_` are both present then the code within the
`else` would be marked as unreadable.

Edge cases:
1. If the `_` pattern in present in any of the contained matches and the `else` block is also
present then a `unreachable_code` lint is emitted on the code within the `else` block
2. Since the main reason for using a `match` is the exhaustiveness checks as long as there isn't
an `else` block then the compiler will output an error for `non-exhaustive patterns` if not all
branches of the `match/in` are exhaustive.
branches of the `match/fallthrough` are exhaustive.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another possibility would be to use ! (never type) pattern instead of else to make the syntax more terse.
This would work because let value: T = panic!(); where T is any type is valid - i.e: bottom inhabits every type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So would it be the following (for clarification):

match many x {
    _ if x % 5 == 0 => expr,
    ! => expr
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely see the appeal of it, since as you say it is much more terse, but I think that it would be more confusing since it is in the area of pat/expr of the expression but does not follow the same "rules" as the other patterns since it will only be executed if no other patterns are executed sort of how the else block of an if statement is only executed if none of the other ifs or else ifs are executed

Implementation Assumptions:
1. Assuming that a `match` expression is currently implemented similar to a long chain of
Expand All @@ -78,9 +79,9 @@ branches then it is set to immediately after the `else` block.
# How We Teach This
[how-we-teach-this]: #how-we-teach-this

This should be called `match/in` expressions since that is the combination of keywords that are
used similar to `for/in` expressions. This idea would be best presented as a continuation of
existing Rust patterns since it expands on the `match` expression.
This should be called `match/fallthrough` expressions since that is the combination of keywords
that are used. This idea would be best presented as a continuation of existing Rust patterns
since it expands on the `match` expression.

This proposal should be introduced to new users right after `match` expressions are taught. This
is the best time to teach it since it appears as an extension of that syntax and the ideas that
Expand Down Expand Up @@ -116,7 +117,7 @@ match cmp.compare(&array[left], &array[right]) {
```
into
```rust
match cmp.compare(&array[left], &array[right]) in {
match fallthrough cmp.compare(&array[left], &array[right]) {
Less | Equal => {
merged.push(array[left]);
left += 1;
Expand Down Expand Up @@ -148,7 +149,7 @@ for x in 1...100 {
into
```rust
for x in 1...100 {
match x in {
match fallthrough x {
_ if x % 5 == 0 => print!("fizz"),
_ if x % 7 == 0 => print!("buzz")
} else {
Expand Down Expand Up @@ -180,4 +181,4 @@ to have and so not implementing it could be an option.
# Unresolved questions
[unresolved]: #unresolved-questions

Whether or not `match/in` makes sense for this sort of control flow.
Whether or not `match/fallthrough` makes sense for this sort of control flow.