From d61d1f2e1ff109a78cf2569d2f6089cd8d128c55 Mon Sep 17 00:00:00 2001 From: "WATGAMER\\snmalton" Date: Thu, 27 Jul 2017 13:39:02 -0400 Subject: [PATCH 1/5] inital RFC commit --- text/0000-warning-on-tautology-else.md | 60 ++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 text/0000-warning-on-tautology-else.md diff --git a/text/0000-warning-on-tautology-else.md b/text/0000-warning-on-tautology-else.md new file mode 100644 index 00000000000..105043d37ba --- /dev/null +++ b/text/0000-warning-on-tautology-else.md @@ -0,0 +1,60 @@ +- Feature Name: warning_on_tautology_else +- Start Date: 2017-07-27 +- RFC PR: +- Rust Issue: + +# Summary +[summary]: #summary + +When the compiler can statically determine if an if branch will always be `true` or `false` then a compiler warning should be outputted saying something like: `tautology detected else branch unreachable` or `contradiction detected if branch unreachable`. + +# Motivation +[motivation]: #motivation + +The motivation behind this so that the programmer can be told about items that may be logical mistakes. + +# Detailed design +[design]: #detailed-design + +When going through the branch detection if an expression within an if statement is true or if the expression is false within an if or while statement then the warning should be outputted. +Since this is a compiler warning the ability to ignore it should be also allowed so using a macro like `cfg!` does not throw this warning. +So either the compiler should look for the `#[allow]` statement before an if/while statement (which is currently not allowed) or head of where the value is defined. +The former seems like a more intuitive solution because it places the `#[allow]` in the context of where it will apply. + +# How We Teach This +[how-we-teach-this]: #how-we-teach-this + +This can be taught by adding to the books by adding examples like the following which will show the warnings in action. + +```rust +if x > 5 && x < 5 { + call_fn(); +} else { + call_other_fn(); +} + +------------------------------ + +warning: contradiction in if statement, associated block unreachable +1 | / if x > 5 && x < 5 { +2 | | call_fn(); +3 | | } else { +4 | | call_other_fn(); +5 | | } + | |_____^ + | + = note: #[warn(tautology-contradiction)] on by default +``` + +# Drawbacks +[drawbacks]: #drawbacks + +This would require allowing `#[allow]` to be placed before `if` and `while` statements + +# Alternatives +[alternatives]: #alternatives + +The impact of not doing this would be little since it is a warning addition which is currently not present. + +# Unresolved questions +[unresolved]: #unresolved-questions From 73e34ec57bb58e15beed1e9f8291d3f4e0c10ad0 Mon Sep 17 00:00:00 2001 From: Sebastian Malton Date: Sun, 10 Sep 2017 15:26:05 -0400 Subject: [PATCH 2/5] Inital commit for the overlapping_match rfc --- text/0000-overlapping_match.md | 150 +++++++++++++++++++++++++ text/0000-warning-on-tautology-else.md | 60 ---------- 2 files changed, 150 insertions(+), 60 deletions(-) create mode 100644 text/0000-overlapping_match.md delete mode 100644 text/0000-warning-on-tautology-else.md diff --git a/text/0000-overlapping_match.md b/text/0000-overlapping_match.md new file mode 100644 index 00000000000..1d34e31fc6f --- /dev/null +++ b/text/0000-overlapping_match.md @@ -0,0 +1,150 @@ +- Feature Name: overlapping_match_statements +- Start Date: 2017-09-08 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary +[summary]: #summary + +This feature is to facilitate the writing and using of `match` statements in a whole new way. +This feature would allow the ability to write match statements where multiple branches may be +matched and still allow for code to be used if no branch is matched, similar to the current +use of the `_` pattern. + +# Motivation +[motivation]: #motivation + +There is a very good software engineering principle where repeating a piece of code is bad. +This is the case because if that selection of code needs to be changed then it has to be +changed in two places which can easily not be done and thus create bugs. A way of doing this +for a large selection of lines of code is to put it into a function, a helper function. Allowing +overlapping match statements extends this paradigm to that where matching is a good idea, the +use of pattern matching, and where exhaustiveness checks are a nice thing. + +This would support use cases where the required execution of several branches overlapped enough +that his would help. A use case for this is when the outcome of one branch is the same as a +combination of the other two branches of a match statement. The expected outcome of this is +the ability to have multiple branches of a match statement, and having those branches still be +checked for exhaustiveness, be executed if more than one of them match the value. + +# Detailed design +[design]: #detailed-design + +Basic Syntax: +```rust +match val in { + pat | pat => expr, + pat => expr +} + +match val in { + pat | pat => expr, + pat => expr +} else { + expr +} +``` + +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 breaks. +2. The `in` seems to imply that it sort of like an "iterator" of statements and will go through +each of them in turn. + +Meaning of parts: +1. The `else` is used in a similar sort of vein to that of the `_` pattern in normal matches and +could include several of the same warnings. The expression enclosed within this is only executed +if none of the patterns within the `match/in` statement. + +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 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`. + +Implementation Assumptions: +1. Assuming that a `match` statement is currently implemented similar to a long chain of +`if/else if` statements. + +Implementation: +1. This can be implemented as if it was a list of `if` statements. +2. To cover the `else` case the location to jump to at the end after checking all the branches +can be stored, initially set to the start of the `else` block but if it enters any of the +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` statements since that is the combination of keywords that are +used similar to `for/in` statements. This idea would be best presented as a continuation of +existing Rust patterns since it expands on the `match` statement. + +This proposal should be introduced to new users right after `match` statements are taught. This +is the best time to teach it since it appears as an extension of that syntax and the ideas that +are used when using `match` statements. + +Within the _Rust Book_ a section after the section on the `_` placeholder could be called +_match/in Control Flow Operator Addition_. Within this section the syntax and differences would +be outlined. These would most notable include the multiple branches can be executed. The reader +should be able to understand by the end of this section that this allows for multiple branches +to be executed but it still will check for exhaustiveness when able. He should also know that +the branches are checked top first. + +An example that could be used within the section: + +You can turn this: +```rust +match cmp.compare(&array[left], &array[right]) { + Less => { + merged.push(array[left]); + left += 1; + }, + Equal => { + merged.push(array[left]); + merged.push(array[right]); + left += 1; + right += 1; + }, + Greater => { + merged.push(array[right]); + right += 1; + } +} +``` +into +```rust +match cmp.compare(&array[left], &array[right]) in { + Less | Equal => { + merged.push(array[left]); + left += 1; + }, + Greater | Equal => { + merged.push(array[right]); + right += 1; + } +} +``` + +# Drawbacks +[drawbacks]: #drawbacks + +This should not be done because it increases the size of language and might not be used by +everyone. + +# Alternatives +[alternatives]: #alternatives + +1. Instead of using `match` as a basis instead removing patterns from the equation and having +some notation that asks the compiler to prove that some value will be set to true by the time +a certain point in the code has been reached. This has some downfalls: + 1. It requires the compiler to prove something as true which the compiler currently does not + do so that would require a lot more work. + 2. There does not seem to be any syntax that makes sense to use in this case without adding + a new keyword and avoiding that is preferable +2. Not doing anything, since the old code works and is somewhat usable this idea is not necessary +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. diff --git a/text/0000-warning-on-tautology-else.md b/text/0000-warning-on-tautology-else.md deleted file mode 100644 index 105043d37ba..00000000000 --- a/text/0000-warning-on-tautology-else.md +++ /dev/null @@ -1,60 +0,0 @@ -- Feature Name: warning_on_tautology_else -- Start Date: 2017-07-27 -- RFC PR: -- Rust Issue: - -# Summary -[summary]: #summary - -When the compiler can statically determine if an if branch will always be `true` or `false` then a compiler warning should be outputted saying something like: `tautology detected else branch unreachable` or `contradiction detected if branch unreachable`. - -# Motivation -[motivation]: #motivation - -The motivation behind this so that the programmer can be told about items that may be logical mistakes. - -# Detailed design -[design]: #detailed-design - -When going through the branch detection if an expression within an if statement is true or if the expression is false within an if or while statement then the warning should be outputted. -Since this is a compiler warning the ability to ignore it should be also allowed so using a macro like `cfg!` does not throw this warning. -So either the compiler should look for the `#[allow]` statement before an if/while statement (which is currently not allowed) or head of where the value is defined. -The former seems like a more intuitive solution because it places the `#[allow]` in the context of where it will apply. - -# How We Teach This -[how-we-teach-this]: #how-we-teach-this - -This can be taught by adding to the books by adding examples like the following which will show the warnings in action. - -```rust -if x > 5 && x < 5 { - call_fn(); -} else { - call_other_fn(); -} - ------------------------------- - -warning: contradiction in if statement, associated block unreachable -1 | / if x > 5 && x < 5 { -2 | | call_fn(); -3 | | } else { -4 | | call_other_fn(); -5 | | } - | |_____^ - | - = note: #[warn(tautology-contradiction)] on by default -``` - -# Drawbacks -[drawbacks]: #drawbacks - -This would require allowing `#[allow]` to be placed before `if` and `while` statements - -# Alternatives -[alternatives]: #alternatives - -The impact of not doing this would be little since it is a warning addition which is currently not present. - -# Unresolved questions -[unresolved]: #unresolved-questions From daf503da226c55de3fd15c872e7cf2396d66dede Mon Sep 17 00:00:00 2001 From: Sebastian Malton Date: Sun, 10 Sep 2017 22:00:43 -0400 Subject: [PATCH 3/5] Rewriting some of the parts and adding another example of a use --- text/0000-overlapping_match.md | 69 +++++++++++++++++++++++++--------- 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/text/0000-overlapping_match.md b/text/0000-overlapping_match.md index 1d34e31fc6f..53f264f2c4f 100644 --- a/text/0000-overlapping_match.md +++ b/text/0000-overlapping_match.md @@ -6,10 +6,9 @@ # Summary [summary]: #summary -This feature is to facilitate the writing and using of `match` statements in a whole new way. -This feature would allow the ability to write match statements where multiple branches may be -matched and still allow for code to be used if no branch is matched, similar to the current -use of the `_` pattern. +This idea facilitates the writing and using of `match` expressions where multiple branches are +executed. Writing `match` expressions with this idea allows for multiple branches to be matched +and for a check on no matches as well, similar to the current use of the `_` pattern. # Motivation [motivation]: #motivation @@ -47,27 +46,31 @@ 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 breaks. +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. Meaning of parts: -1. The `else` is used in a similar sort of vein to that of the `_` pattern in normal matches and -could include several of the same warnings. The expression enclosed within this is only executed -if none of the patterns within the `match/in` statement. +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 +`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 on the code within the `else` block +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`. +an `else` block then the compiler will output an error for `non-exhaustive patterns` if not all +branches of the `match/in` are exhaustive. Implementation Assumptions: -1. Assuming that a `match` statement is currently implemented similar to a long chain of -`if/else if` statements. +1. Assuming that a `match` expression is currently implemented similar to a long chain of +`if/else if` expressions. By this, meaning that each branch is checked one at a time and if it +matches then it skips checking any of the other branches and jumps to the end of the expression. Implementation: -1. This can be implemented as if it was a list of `if` statements. +1. This can be implemented as if it was a list of `if` expressions. And a flag to check if any +of the branches have been visited so as to not visit the `else` 2. To cover the `else` case the location to jump to at the end after checking all the branches can be stored, initially set to the start of the `else` block but if it enters any of the branches then it is set to immediately after the `else` block. @@ -75,13 +78,13 @@ 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` statements since that is the combination of keywords that are -used similar to `for/in` statements. This idea would be best presented as a continuation of -existing Rust patterns since it expands on the `match` statement. +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 proposal should be introduced to new users right after `match` statements are taught. This +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 -are used when using `match` statements. +are used when using `match` expressions. Within the _Rust Book_ a section after the section on the `_` placeholder could be called _match/in Control Flow Operator Addition_. Within this section the syntax and differences would @@ -125,6 +128,36 @@ match cmp.compare(&array[left], &array[right]) in { } ``` +Another example is an implementation of fizzbuzz: + +```rust +for x in 1...100 { + let mut res = String::from(""); + if x % 5 == 0 { + res += "fizz"; + } + if x % 7 == 0 { + res += "buzz"; + } + if res.len() == 0 { + res = x.to_string(); + } + println!("{}", res); +} +``` +into +```rust +for x in 1...100 { + match x in { + _ if x % 5 == 0 => print!("fizz"), + _ if x % 7 == 0 => print!("buzz") + } else { + print!("{}", x); + } + println!(""); +} +``` + # Drawbacks [drawbacks]: #drawbacks From 8f064a97051b7c7a36e49c3a7e0c9d364484d992 Mon Sep 17 00:00:00 2001 From: Sebastian Malton Date: Mon, 11 Sep 2017 09:18:46 -0400 Subject: [PATCH 4/5] Changing the syntax over to "match fallthrough" --- text/0000-overlapping_match.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/text/0000-overlapping_match.md b/text/0000-overlapping_match.md index 53f264f2c4f..6536259aafb 100644 --- a/text/0000-overlapping_match.md +++ b/text/0000-overlapping_match.md @@ -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 { @@ -45,15 +45,16 @@ 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. 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: @@ -61,7 +62,7 @@ Edge cases: 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. Implementation Assumptions: 1. Assuming that a `match` expression is currently implemented similar to a long chain of @@ -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 @@ -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; @@ -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 { @@ -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. From dee68cc59c37da9d771ebe3f981041853027a411 Mon Sep 17 00:00:00 2001 From: Sebastian Malton Date: Mon, 11 Sep 2017 17:59:51 -0400 Subject: [PATCH 5/5] Changing the text to `match many` since fallthrough would imply usage like a C-style `switch` statement and `match all` impies that every branch is automatically matched --- text/0000-overlapping_match.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/text/0000-overlapping_match.md b/text/0000-overlapping_match.md index 6536259aafb..5b5f7ff7585 100644 --- a/text/0000-overlapping_match.md +++ b/text/0000-overlapping_match.md @@ -31,12 +31,12 @@ checked for exhaustiveness, be executed if more than one of them match the value Basic Syntax: ```rust -match fallthrough val { +match many val { pat | pat => expr, pat => expr } -match fallthrough val { +match many val { pat | pat => expr, pat => expr } else { @@ -48,13 +48,13 @@ Benefits of this syntax: 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 +2. The word `many` is used because it implies that after a branch is finished then the control falls through to the check of the next branch. 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/fallthrough` expression are matched. If `else` and `_` are both present then the code within the +`match/many` expression are matched. If `else` and `_` are both present then the code within the `else` would be marked as unreadable. Edge cases: @@ -62,7 +62,7 @@ Edge cases: 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/fallthrough` are exhaustive. +branches of the `match/many` are exhaustive. Implementation Assumptions: 1. Assuming that a `match` expression is currently implemented similar to a long chain of @@ -79,7 +79,7 @@ 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/fallthrough` expressions since that is the combination of keywords +This should be called `match/many` 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. @@ -117,7 +117,7 @@ match cmp.compare(&array[left], &array[right]) { ``` into ```rust -match fallthrough cmp.compare(&array[left], &array[right]) { +match many cmp.compare(&array[left], &array[right]) { Less | Equal => { merged.push(array[left]); left += 1; @@ -149,7 +149,7 @@ for x in 1...100 { into ```rust for x in 1...100 { - match fallthrough x { + match many x { _ if x % 5 == 0 => print!("fizz"), _ if x % 7 == 0 => print!("buzz") } else { @@ -181,4 +181,4 @@ to have and so not implementing it could be an option. # Unresolved questions [unresolved]: #unresolved-questions -Whether or not `match/fallthrough` makes sense for this sort of control flow. +Whether or not `match/many` makes sense for this sort of control flow.