Tracking issue for RFC 2591: precise pattern matching on pointer size types

[varkor]

This is a tracking issue for (precise) exhaustive pattern matching on usize and isize (described in rust-lang/rfcs#2591).

Feature gate: #![feature(precise_pointer_size_matching)]

Steps:

• Implement the RFC (Stabilise exhaustive integer patterns #56362)
• Stabilization PR (see instructions on forge)

[SergioBenitez]

Is there anything preventing the stabilization of this feature?

[varkor]

I think we'd need an RFC, or at the very least, a detailed motivation. The problem is that pointer size types have different ranges depending on the target platform, and so there was concern that this could cause confusion. See rust-lang/rfcs#2591 (comment) and rust-lang/rfcs#2591 (comment) for details.

[workingjubilee]

I believe that if half_open_range_patterns receive partial or total stabilization as discussed in #67264, it might allow for patterns that more usefully handle various cases here. This could be particularly useful when you want to match on e.g. the length of an array, Vec, or anything else that would produce an ExactSizeIterator (an example I have seen is matching against the count of arguments to a CLI).

[roblabla]

I am so confused by this. I currently have code to the effect of

match 0usize {
    0..=9 => { /* some code that only runs on small numbers */ },
    10.. => { /* some code that handles everything else */ },
}

This triggers this hard error. I'm... not sure I understand the rationale behind this.

I can understand denying precise pointer matching when hardcoding numbers, but it seems to me like half-open ranges should obviously be accepted here - there is no room for any confusion or portability issues. And this isn't even a lint, so we can't #[allow] it away...

Could half-open ranges on usize be allowed to exhaustively match?