Skip to content

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

New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom
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: An issue tracking the progress of sth. like the implementation of an RFC 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 •
edited by Nadrieril
Loading

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: An issue tracking the progress of sth. like the implementation of an RFC labels Nov 30, 2018
@varkor varkor mentioned this issue Oct 23, 2019
Closed
@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.

@Nadrieril Nadrieril mentioned this issue Nov 28, 2020
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 29, 2020
@bors
Auto merge of rust-lang#79523 - Nadrieril:fix-usize-ranges, r=varkor
b776d1c 
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).

@workingjubilee workingjubilee mentioned this issue Sep 23, 2021
Closed
@joshtriplett joshtriplett added the S-tracking-design-concerns Status: There are blocking design concerns. label Jun 8, 2022
@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 •
edited
Loading

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.

@workingjubilee workingjubilee self-assigned this Mar 5, 2023
@lukas-code lukas-code mentioned this issue May 23, 2023
Closed
@Jules-Bertholet Jules-Bertholet mentioned this issue Jun 26, 2023
Closed
@KSBilodeau KSBilodeau mentioned this issue Sep 3, 2023
Closed
@workingjubilee workingjubilee removed their assignment Oct 15, 2023
@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 Nadrieril mentioned this issue Dec 4, 2023
Merged
@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
@rust-timer
Unrolled build for rust-lang#118598
0a6f57d 
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
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
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: An issue tracking the progress of sth. like the implementation of an RFC 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
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove the precise_pointer_size_matching feature gate Nadrieril/rust
8 participants
@joshtriplett @Centril @roblabla @SergioBenitez @jonas-schievink @varkor @Nadrieril @workingjubilee