Thanks @mdinger, fixed.

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.

@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.

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.

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.

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

(It's not a priority although).

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

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