Tracking issue for RFC 2591: precise pattern matching on pointer size types #56354
Comments
Centril
added
T-lang
jonas-schievink
added
the
B-unstable
|
Is there anything preventing the stabilization of this feature? |
|
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. |
Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm, because the range of values they contain depends on the platform. Specifically, we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](rust-lang#56354)). The way this was initially implemented is by treating those ranges like float ranges, i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {}, 10..20 => {}, 5..15 => {}, // oops, should be detected as unreachable _ => {}, } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking
workingjubilee
added
A-exhaustiveness-checking
|
I believe that if |
joshtriplett
added
the
S-tracking-design-concerns
|
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 Could half-open ranges on usize be allowed to exhaustively match? |
|
I will write up a formal proposal for this, as I attempted to move half-open range patterns along a bit so that we could specifically have this. |
|
@roblabla's example above now works as expected. Given that half-open ranges can now be used to match exhaustively on |
|
In #118598 I propose to deprecate this feature gate in favor of half-open range patterns |
Rollup merge of rust-lang#118598 - Nadrieril:remove_precise_pointer_size_matching, r=davidtwco Remove the `precise_pointer_size_matching` feature gate `usize` and `isize` are special for pattern matching because their range might depend on the platform. To make code portable across platforms, the following is never considered exhaustive: ```rust let x: usize = ...; match x { 0..=18446744073709551615 => {} } ``` Because of how rust handles constants, this also unfortunately counts `0..=usize::MAX` as non-exhaustive. The [`precise_pointer_size_matching`](rust-lang#56354) feature gate was introduced both for this convenience and for the possibility that the lang team could decide to allow the above. Since then, [half-open range patterns](rust-lang#67264) have been implemented, and since rust-lang#116692 they correctly support `usize`/`isize`: ```rust match 0usize { // exhaustive! 0..5 => {} 5.. => {} } ``` I believe this subsumes all the use cases of the feature gate. Moreover no attempt has been made to stabilize it in the 5 years of its existence. I therefore propose we retire this feature gate. Closes rust-lang#56354
This is a tracking issue for (precise) exhaustive pattern matching on
usizeandisize(described in rust-lang/rfcs#2591).Feature gate:
#![feature(precise_pointer_size_matching)]Steps:
The text was updated successfully, but these errors were encountered: