Skip to content
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

Tracking Issue for generic pattern types #136574

Open
4 tasks
oli-obk opened this issue Feb 5, 2025 · 0 comments
Open
4 tasks

Tracking Issue for generic pattern types #136574

oli-obk opened this issue Feb 5, 2025 · 0 comments
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 stablize). 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
Copy link
Contributor

oli-obk commented Feb 5, 2025

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

  • Should we allow these at all?
  • How can we solve this with min const generic expressions?
  • Should we have an implied bound for all signatures that have such a pattern type?

Implementation history
@oli-obk oli-obk added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Feb 5, 2025
@jieyouxu jieyouxu added A-patterns Relating to patterns and pattern matching 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. B-experimental Blocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stablize). labels Feb 5, 2025
@oli-obk oli-obk mentioned this issue Feb 5, 2025
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 10, 2025
@matthiaskrgr
Rollup merge of rust-lang#136584 - oli-obk:pattern-types-generic, r=B…
65d1218 
…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
@matthiaskrgr
Rollup merge of rust-lang#136584 - oli-obk:pattern-types-generic, r=B…
afdb51a 
…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
@matthiaskrgr
Rollup merge of rust-lang#136584 - oli-obk:pattern-types-generic, r=B…
c92aae9 
…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
@rust-timer
Unrolled build for rust-lang#136584
6008d73 
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``
@nikomatsakis nikomatsakis moved this to Exploration in Lang team champions Feb 21, 2025
@nikomatsakis nikomatsakis moved this from Exploration to Uncategorized in Lang team champions Feb 21, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
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 stablize). 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.
Projects
Lang team champions
Status: Needs champion
Milestone
No milestone
Development

No branches or pull requests
2 participants
@oli-obk @jieyouxu