Closed
Description
Issue by Manishearth
Friday Jun 27, 2014 at 17:41 GMT
For earlier discussion, see rust-lang/rust#15219
This issue was labelled with: B-RFC, I-papercut in the Rust repository
If I have a match arm like this:
0x2A | 0x2D | 0x2E | 0x30 .. 0x39 | 0x41 .. 0x5A | 0x5F | 0x61..0x7A => {}
the following does not work:
a @ 0x2A | 0x2D | 0x2E | 0x30 .. 0x39 | 0x41 .. 0x5A | 0x5F | 0x61..0x7A => {println("{}",a)}
a @ (0x2A | 0x2D | 0x2E | 0x30 .. 0x39 | 0x41 .. 0x5A | 0x5F | 0x61..0x7A) => {println("{}",a)}
In the former example, the a
is bound to the first literal only, and in the latter the compiler thinks that it is a tuple (and complains about the lack of commas).
Of course, one can do
a @ 0x2A | a @ 0x2D | a@ 0x2E | a@ 0x30 .. 0x39 /* etc */=> {println("{}",a)}
but that is cumbersome.
Could we get a way to easily bind a variable to the entire match arm?
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
mtdowling commentedon Apr 13, 2015
👍. It would be much easier to use complex matching if you can label the whole arm at once.
pnkfelix commentedon Apr 13, 2015
Just to be clear ... this is only an issue if you are working with data that is being moved into the arm's pattern, right? (Because otherwise you should just be able to bind the match's input to a variable at the outset, and then use that variable within the arm...)
But maybe I a missing a use-case here.
mtdowling commentedon Apr 13, 2015
That's basically my use case. Having to define a variable outside of the match turns what could be a single expression (e.g., matching on the result of an expression) into a statement and expression.
gsingh93 commentedon Apr 16, 2015
+1, just ran into this.
petrochenkov commentedon Jan 29, 2018
This is a subset of #1882
Centril commentedon Oct 7, 2018
Closing in favor of rust-lang/rust#54883. We already have
pattern_parenthesis
for the other part.