Improvements to range match patterns

[quantheory]

We can currently use patterns of the form 2...5 in matches, but not 2... or ...5 (which one would expect by analogy with RangeTo/RangeFrom). This RFC adds those new forms; I will update it if the existing pattern range syntax is going to change.

Additionally, this RFC proposes performing exhaustiveness checks on patterns for integer types and char.

Note: Since there are a lot of RFC PRs recently, including several that I've proposed, I want to note that this one in particular poses a (rather minor) backwards compatibility issue. Some rare match patterns that compile now would be rejected.

Rendered.

[mdinger]

Shouldn't it be:
...j will match all numbers less than j?

[quantheory]

Thanks @mdinger, fixed.

[oli-obk]

Since ... is inclusive, what would be the difference between 2.. and 2... (just in case http://internals.rust-lang.org/t/vs-for-inclusive-ranges/1539/50 gets further). Also there would be no difference at all between ..5 and ...5.

[quantheory]

@oli-obk To be honest, I found it a bit difficult to figure out the front-runner in that thread, since there are a lot of different suggestions there, and so I basically decided to ignore it until there's some specific proposal that comes out of that discussion.

If exclusive ranges were allowed in patterns, I would say that 2.. and 2... would presumably be identical, while ..5 would not include 5, and ...5 would include 5. Whether the exclusive ranges are likely to be added, and whether they would replace or supplement the inclusive ranges, is orthogonal to this RFC IMO.

[nikomatsakis]

Hmm. This seems like a nice thing to have, but I think it's probably going to have to come after 1.0, which implies that the exhaustiveness checking will have to be weaker, which is probably ok.

[nrc]

We discussed this at the triage meeting today. We all thought it was probably a nice addition to the language, however, it is too low priority to consider before 1.0. Therefore I will close this as postponed. Tracking issue is #947.

[vi]

Bump. I except this and semiopen 0..128 to be included someday.

(It's not a priority although).

[pnkfelix]

(Added #1550 as a separate tracking issue for the exhaustiveness suggestion, which is arguably orthogonal to the half-open ranges being tracked in #947.)

[carloslbello]

Is there any possibility of this getting split into two RFCs? I'm specifically interested in the exhaustive pattern matching.