From caf1efcfdd0398b1bc604c06b124a75d839a2a2e Mon Sep 17 00:00:00 2001 From: Aaron Power Date: Fri, 3 Feb 2017 15:21:18 +0000 Subject: [PATCH 1/3] Allow use of pipe operator in sub expressions. --- text/0000-pipe-in-sub-expressions.md | 69 ++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 text/0000-pipe-in-sub-expressions.md diff --git a/text/0000-pipe-in-sub-expressions.md b/text/0000-pipe-in-sub-expressions.md new file mode 100644 index 00000000000..39673c1a255 --- /dev/null +++ b/text/0000-pipe-in-sub-expressions.md @@ -0,0 +1,69 @@ +- Feature Name: pipe_in_sub_expressions. +- Start Date: 2017-02-03 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +## Summary +this RFC proposes allowing the `|` operator to be used within patterns in match +statements, to allow for pattern matching with less boilerplate. + +## Detailed Design +The current pattern matching in `match` statements is very powerful, however +there is a lot of boilerplate code needed to fully take advantage of it. +Consider a situation where you are building a state machine that is iterating +through `chars_indices`, and when you see `' '`, `'\n'`, `'\r'` or `'\f'`, you +want to change the state. Currently your match statement would look something +like the following example. There is no great way of reducing that boilerplate, +if anything that boilerplate only grows worse as you have more cases, and bigger +tuples. Conservatively this feature would be simple syntactic sugar that just +expands to the old syntax. + +```rust +match iter.next() { + Some(_, ' ') | Some(_, '\n') | Some(_, '\r') | Some(_, '\u{21A1}') => { + // Change state + } + Some(index, ch) => { + // Look at char + } + None => return Err(Eof), +} +``` + +The solution to this would be to allow for `|` to be used within tuples. This +will significantly reduce how much boilerplate is required to have conditional +matches with tuples. + +```rust +match iter.next() { + Some(_, ' ' | '\n' | '\r' | '\u{21A1}') => { + // Change state + } + Some(index, ch) => { + // Look at char + } + None => return Err(Eof), +} +``` +In terms of Rust's grammar `pats_or` would probably be changed to the following. +Which should allow for `Some(1 | 2 | 3, ' ' | '\n' | '\r')`. + +```yacc +pats_or +: pat { $$ = mk_node("Pats", 1, $1); } +| pat '|' pat { $$ = ext_node($1, 1, $3); } +; +``` + +## How We Teach This +I think all that would be required is additional examples in sections on +pattern matching. The syntax is very intuitive. + +## Drawbacks +None that I can think of. + +## Alternatives +Keep syntax as is. + +## Unresolved Questions +None at the moment. From 85f052c30bb41734c8edf8f70009a663ddc92540 Mon Sep 17 00:00:00 2001 From: Aaron Power Date: Fri, 3 Feb 2017 17:22:24 +0000 Subject: [PATCH 2/3] Update and rename 0000-pipe-in-sub-expressions.md to 0000-pipe-in-patterns.md --- ...0000-pipe-in-sub-expressions.md => 0000-pipe-in-patterns.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{0000-pipe-in-sub-expressions.md => 0000-pipe-in-patterns.md} (98%) diff --git a/text/0000-pipe-in-sub-expressions.md b/text/0000-pipe-in-patterns.md similarity index 98% rename from text/0000-pipe-in-sub-expressions.md rename to text/0000-pipe-in-patterns.md index 39673c1a255..999bf2bd5d5 100644 --- a/text/0000-pipe-in-sub-expressions.md +++ b/text/0000-pipe-in-patterns.md @@ -1,4 +1,4 @@ -- Feature Name: pipe_in_sub_expressions. +- Feature Name: pipe_in_patterns. - Start Date: 2017-02-03 - RFC PR: (leave this empty) - Rust Issue: (leave this empty) From de235887a80555427314c7eb25c6214523d50cce Mon Sep 17 00:00:00 2001 From: Aaron Power Date: Fri, 10 Feb 2017 12:31:39 +0000 Subject: [PATCH 3/3] Update 0000-pipe-in-patterns.md --- text/0000-pipe-in-patterns.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/text/0000-pipe-in-patterns.md b/text/0000-pipe-in-patterns.md index 999bf2bd5d5..73a20c78c18 100644 --- a/text/0000-pipe-in-patterns.md +++ b/text/0000-pipe-in-patterns.md @@ -4,14 +4,14 @@ - Rust Issue: (leave this empty) ## Summary -this RFC proposes allowing the `|` operator to be used within patterns in match -statements, to allow for pattern matching with less boilerplate. +this RFC proposes allowing the `|` operator to be used within patterns to +allow for pattern matching with less boilerplate. ## Detailed Design -The current pattern matching in `match` statements is very powerful, however -there is a lot of boilerplate code needed to fully take advantage of it. -Consider a situation where you are building a state machine that is iterating -through `chars_indices`, and when you see `' '`, `'\n'`, `'\r'` or `'\f'`, you +The current pattern matching is very powerful, however there is a lot of +boilerplate code needed to fully take advantage of it. Consider a +situation where you are building a state machine that is iterating through +`chars_indices`, and when you see `' '`, `'\n'`, `'\r'` or `'\f'`, you want to change the state. Currently your match statement would look something like the following example. There is no great way of reducing that boilerplate, if anything that boilerplate only grows worse as you have more cases, and bigger @@ -30,7 +30,7 @@ match iter.next() { } ``` -The solution to this would be to allow for `|` to be used within tuples. This +The solution to this would be to allow for `|` to be used within patterns. This will significantly reduce how much boilerplate is required to have conditional matches with tuples.