Tracking Issue for generic pattern types #136574
Labels
A-patterns
Relating to patterns and pattern matching
B-experimental
Blocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
T-types
Relevant to the types team, which will review and decide on the PR/issue.
Comments
oli-obk
added
the
C-tracking-issue
jieyouxu
added
A-patterns
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 10, 2025
…oxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? `@lcnr` cc `@scottmcm` `@joshtriplett`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 10, 2025
…oxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? `@lcnr` cc `@scottmcm` `@joshtriplett`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 11, 2025
…oxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? ``@lcnr`` cc ``@scottmcm`` ``@joshtriplett``
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 11, 2025
Rollup merge of rust-lang#136584 - oli-obk:pattern-types-generic, r=BoxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? ``@lcnr`` cc ``@scottmcm`` ``@joshtriplett``
|
Hopefully this is the right place to write this. For me the (hard) requirement of pattern types (or similar Rust features) is this to compile and it to not contain a run-time array bound test: type I10 = usize is 0 .. 10;
const fn foo(a: [i32; 10], i: I10) -> i32 {
a[i]
}Other nice to have subfeatures is (using this I10 as an example) the values I10::MIN, I10::MAX, and I10::RANGE (that's a Range, assuming the ID isn't a union of multiple intervals). |
|
Please avoid using tracking issues for discussions. Tracking issues become unmanageable quickly. There's a dedicated Zulip stream for absolutely anything you want to talk about on pattern types: https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The feature gate for the issue is
#![feature(generic_pattern_types)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Use the associated zulip thread for discussions.
Steps
Unresolved Questions
Implementation history
The text was updated successfully, but these errors were encountered: