Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 of 2 tasks
varkor opened this issue Nov 29, 2018 · 7 comments · Fixed by #118598
Closed
1 of 2 tasks

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

varkor opened this issue Nov 29, 2018 · 7 comments · Fixed by #118598
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns A-patterns Relating to patterns and pattern matching B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-design-concerns Status: There are blocking ❌ design concerns. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@varkor
Copy link
Member

varkor commented Nov 29, 2018

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:

@Centril Centril added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Nov 30, 2018
@jonas-schievink jonas-schievink added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Oct 23, 2019
@SergioBenitez
Copy link
Contributor

Is there anything preventing the stabilization of this feature?

@varkor
Copy link
Member Author

varkor commented Oct 23, 2019

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.

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 29, 2020
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 workingjubilee added A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns A-patterns Relating to patterns and pattern matching labels Apr 9, 2021
@workingjubilee
Copy link
Member

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
Copy link
Contributor

roblabla commented Oct 4, 2022

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?

@workingjubilee
Copy link
Member

workingjubilee commented Mar 5, 2023

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.

@Nadrieril
Copy link
Member

@roblabla's example above now works as expected. Given that half-open ranges can now be used to match exhaustively on usize/isize, is this feature still useful?

@Nadrieril
Copy link
Member

In #118598 I propose to deprecate this feature gate in favor of half-open range patterns

@bors bors closed this as completed in 81b6263 Dec 5, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 5, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns A-patterns Relating to patterns and pattern matching B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-design-concerns Status: There are blocking ❌ design concerns. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants