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.

Sign up for GitHub

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

Jump to bottom

Exhaustive integer patterns tracking issue #50907

Closed
2 tasks done
varkor opened this issue May 19, 2018 · 17 comments
Closed
2 tasks done

Exhaustive integer patterns tracking issue #50907

varkor opened this issue May 19, 2018 · 17 comments
Labels
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 F-exclusive_range_pattern `#![feature(exclusive_range_pattern)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@varkor
Copy link
Member

varkor commented May 19, 2018 •
edited
Loading

Tentative tracking issue for the exhaustive_integer_patterns feature, in which integer types may be exhaustively matched over their values. Original RFC thread: rust-lang/rfcs#1550.

#![feature(exhaustive_integer_patterns)]
#![feature(exclusive_range_pattern)]

fn matcher(x: u8) {
  match x { // ok -- every value has been accounted for
    0 .. 32 => { /* foo */ }
    32 => { /* bar */ }
    33 ..= 255 => { /* baz */ }
  }
}
@leonardo-m

This comment has been minimized.

Sign in to view
@varkor

This comment has been minimized.

Sign in to view
This was referenced May 20, 2018
Merged
Closed
@ishitatsuyuki

This comment has been minimized.

Sign in to view
@kennytm kennytm added T-lang Relevant to the language team, which will review and decide on the PR/issue. 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 labels May 20, 2018
@leonardo-m

This comment has been minimized.

Sign in to view
@ishitatsuyuki

This comment has been minimized.

Sign in to view
@leonardo-m

This comment has been minimized.

Sign in to view
@samlh

This comment has been minimized.

Sign in to view
@leonardo-m

This comment has been minimized.

Sign in to view
bors added a commit that referenced this issue Aug 22, 2018
@bors
Auto merge of #50912 - varkor:exhaustive-integer-matching, r=arielb1
a79cffb 
Exhaustive integer matching

This adds a new feature flag `exhaustive_integer_patterns` that enables exhaustive matching of integer types by their values. For example, the following is now accepted:
```rust
#![feature(exhaustive_integer_patterns)]
#![feature(exclusive_range_pattern)]

fn matcher(x: u8) {
  match x { // ok
    0 .. 32 => { /* foo */ }
    32 => { /* bar */ }
    33 ..= 255 => { /* baz */ }
  }
}
```
This matching is permitted on all integer (signed/unsigned and char) types. Sensible error messages are also provided. For example:
```rust
fn matcher(x: u8) {
  match x { //~ ERROR
    0 .. 32 => { /* foo */ }
  }
}
```
results in:
```
error[E0004]: non-exhaustive patterns: `32u8...255u8` not covered
 --> matches.rs:3:9
  |
6 |   match x {
  |         ^ pattern `32u8...255u8` not covered
```

This implements rust-lang/rfcs#1550 for #50907. While there hasn't been a full RFC for this feature, it was suggested that this might be a feature that obviously complements the existing exhaustiveness checks (e.g. for `bool`) and so a feature gate would be sufficient for now.
@varkor
Copy link
Member Author

varkor commented Aug 22, 2018

This will be usable on the next Nightly under #![feature(exhaustive_integer_patterns)] now that #50912 merged!

@Centril
Copy link
Contributor

Centril commented Sep 15, 2018

N.B: Before we stabilize this, I would like to see an RFC accepted that details and motivates (shouldn't be too hard) the changes.

@varkor
Copy link
Member Author

varkor commented Sep 15, 2018 •
edited
Loading

In #50912 (comment) it was proposed that this extension was filling in a gap in the existing exhaustiveness checks and underwent a T-lang FCP, so an RFC probably isn't necessary here.

@Centril
Copy link
Contributor

Centril commented Sep 16, 2018 •
edited
Loading

@varkor So, I had not read #50912 (comment). However, I do not view exhaustive integer matching as a bugfix or a trivial change. The feature was seen an addition to the language (as opposed to bug-fixes) in previous RFCs and were postponed then since they were not a priority leading up to 1.0. @nikomatsakis said as much in their move to FCP in the linked comment.

Therefore, I do not think that the proper process was followed and I will insist that an RFC is written prior to stabilization because I want to avoid the precedent of allowing larger and larger language changes to be accepted with no RFC.

I want to emphasize that this is not about this particular feature, which I think is an excellent idea and I have no doubt we would merge the RFC; but I do want to see the bits and pieces of text and reasoning that the RFC document provides (and I know that you're capable of writing excellent RFCs). Think of it as a stabilization report. Once we have that RFC merged, we can skip the extra FCP after it.

hcpl added a commit to hcpl/serde_mtproto that referenced this issue Oct 9, 2018
@hcpl
Replace an if-else chain with a pattern match
ec3f9d5 
Due to a compiler limitation, exhaustive integer matches only work on
nightly for now.

See <rust-lang/rust#50907> for details.
hcpl pushed a commit to hcpl/serde_mtproto that referenced this issue Oct 9, 2018
Automatic Travis documentation build
82ed111 
Replace an if-else chain with a pattern match

Due to a compiler limitation, exhaustive integer matches only work on
nightly for now.

See <rust-lang/rust#50907> for details.
@Centril
Copy link
Contributor

Centril commented Nov 10, 2018

@varkor

This has been in the nightly compiler for ~80 days which approximates 12 weeks;
I think it would be appropriate to stabilize this soon.
If you could write the RFC aforementioned we can begin that process.
Also please attach an Appendix to the RFC pointing out relevant test files and such things.

@jonhoo
Copy link
Contributor

jonhoo commented Nov 10, 2018

@Centril should this also be tagged with relnotes when stabilized?

@Centril
Copy link
Contributor

Centril commented Nov 10, 2018

@jonhoo we tag the PR that stabilizes it with relnotes.

@Centril
Copy link
Contributor

Centril commented Nov 10, 2018

Stabilization proposal filed in rust-lang/rfcs#2591.

@Centril Centril mentioned this issue Nov 10, 2018
Merged
@varkor varkor mentioned this issue Nov 30, 2018
Closed
@kurnevsky kurnevsky mentioned this issue Dec 4, 2018
Merged
@bors bors closed this as completed in e57ed0d Dec 6, 2018
@varkor
Copy link
Member Author

varkor commented Dec 6, 2018

This has been stabilised in #56557.

@Centril Centril reopened this Dec 6, 2018
@Centril Centril closed this as completed Dec 6, 2018
@nikic nikic mentioned this issue Dec 8, 2018
Closed
@Centril Centril added the F-exclusive_range_pattern `#![feature(exclusive_range_pattern)]` label Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
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 F-exclusive_range_pattern `#![feature(exclusive_range_pattern)]` 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.

Stabilise exhaustive integer patterns varkor/rust
7 participants
@kennytm @samlh @jonhoo @Centril @varkor @ishitatsuyuki @leonardo-m