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

Pattern types #126

Closed
1 of 3 tasks
oli-obk opened this issue Jan 18, 2024 · 2 comments
Closed
1 of 3 tasks

Pattern types #126

oli-obk opened this issue Jan 18, 2024 · 2 comments
Labels
finished-final-comment-period The FCP has finished, action upon the disposition label needs to be taken major-change A major change proposal major-change-accepted An accepted major change proposal T-types Add this label so rfcbot knows to poll the types team to-announce Announce this issue on triage meeting

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Jan 18, 2024

Proposal

I would like to add minimal pattern types (TyKind::Pat(Ty<'tcx>, Pat<'tcx>) for some definition of Pat<'tcx>). I solely want to add integer range patterns and replace the existing rustc_scalar_layout_start/end attributes with them.

A pattern type is a distinct type from its base type. There is no subtyping relation between pattern types themselves or their base type.

This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.

Creating pattern types will only possible via transmute from the base type. In the future this may become possible via pattern matching, but that needs some care in order to not affect stable code.

Converting pattern types to their base type will only be possible via transmute. In the future this will become possible safely via as casts.

Going beyond this simple new type variant requires an additional MCP. Any additional attempts at adding complexity to this feature may be halted by just referring to this MCP's text.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A types team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Types team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

@oli-obk oli-obk added major-change A major change proposal T-types Add this label so rfcbot knows to poll the types team labels Jan 18, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jan 18, 2024

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/types

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Jan 18, 2024
@BoxyUwU
Copy link
Member

BoxyUwU commented Jan 18, 2024

@rustbot second
on basically the following conditions:

  • This is not "full pattern types", literally just an MVP to replace the existing usages of the rustc_ attribute.
  • Any future extensions should always require another MCP or an FCP so that it's trivial to see if this feature starts expanding in scope past what we have the bandwidth for
  • It does not require any non trivial reasoning about soundness of the type system (I believe this is largely satisfied by the fact that there is no subtyping, the patterns supported would be limited, there is only unsafe construction, and we do not allow impls on them so there is no interaction with coherence)
  • If this starts to cause issues with other features (i.e. stabilizing new solver) we can just rip this out and go back to the rustc_* attr. New solver is already a lot of effort and I don't want us to make that worse. I think this MVP should require almost 0 changes to the new solver, at worst a few builtin impls which ideally should not be too bad.

If we run into additional scope required in order to remove the rustc_* attrs this should also come with an understanding that it might feel like "too much" and scrap this idea for now.

I can probably review this

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jan 18, 2024
@oli-obk oli-obk added major-change-accepted An accepted major change proposal finished-final-comment-period The FCP has finished, action upon the disposition label needs to be taken and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Feb 2, 2024
@oli-obk oli-obk closed this as completed Feb 2, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 5, 2024
…iler-errors

Implement minimal, internal-only pattern types in the type system

rebase of rust-lang#107606

You can create pattern types with `std::pat::pattern_type!(ty is pat)`. The feature is incomplete and will panic on you if you use any pattern other than integral range patterns. The only way to create or deconstruct a pattern type is via `transmute`.

This PR's implementation differs from the MCP's text. Specifically

> This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.

is violated in this PR. The reason is that we do need impls after all in order to make them usable as fields. constants of type `std::time::Nanoseconds` struct are used in patterns, so the type must be structural-eq, which it only can be if you derive several traits on it. It doesn't need to be structural-eq recursively, so we can just manually implement the relevant traits on the pattern type and use the pattern type as a private field.

Waiting on:

* [x] move all unrelated commits into their own PRs.
* [x] fix niche computation (see 2db07f9)
* [x] add lots more tests
* [x] T-types MCP rust-lang/types-team#126 to finish
* [x] some commit cleanup
* [x] full self-review
* [x] remove 61bd325, it's not necessary anymore I think.
* [ ] ~~make sure we never accidentally leak pattern types to user code (add stability checks or feature gate checks and appopriate tests)~~ we don't even do this for the new float primitives
* [x] get approval that [the scope expansion to trait impls](https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/Pattern.20types.20types-team.23126/near/427670099) is ok

r? `@BoxyUwU`
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 8, 2024
…iler-errors

Implement minimal, internal-only pattern types in the type system

rebase of rust-lang#107606

You can create pattern types with `std::pat::pattern_type!(ty is pat)`. The feature is incomplete and will panic on you if you use any pattern other than integral range patterns. The only way to create or deconstruct a pattern type is via `transmute`.

This PR's implementation differs from the MCP's text. Specifically

> This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.

is violated in this PR. The reason is that we do need impls after all in order to make them usable as fields. constants of type `std::time::Nanoseconds` struct are used in patterns, so the type must be structural-eq, which it only can be if you derive several traits on it. It doesn't need to be structural-eq recursively, so we can just manually implement the relevant traits on the pattern type and use the pattern type as a private field.

Waiting on:

* [x] move all unrelated commits into their own PRs.
* [x] fix niche computation (see 2db07f9)
* [x] add lots more tests
* [x] T-types MCP rust-lang/types-team#126 to finish
* [x] some commit cleanup
* [x] full self-review
* [x] remove 61bd325, it's not necessary anymore I think.
* [ ] ~~make sure we never accidentally leak pattern types to user code (add stability checks or feature gate checks and appopriate tests)~~ we don't even do this for the new float primitives
* [x] get approval that [the scope expansion to trait impls](https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/Pattern.20types.20types-team.23126/near/427670099) is ok

r? `@BoxyUwU`
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 8, 2024
…iler-errors

Implement minimal, internal-only pattern types in the type system

rebase of rust-lang#107606

You can create pattern types with `std::pat::pattern_type!(ty is pat)`. The feature is incomplete and will panic on you if you use any pattern other than integral range patterns. The only way to create or deconstruct a pattern type is via `transmute`.

This PR's implementation differs from the MCP's text. Specifically

> This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.

is violated in this PR. The reason is that we do need impls after all in order to make them usable as fields. constants of type `std::time::Nanoseconds` struct are used in patterns, so the type must be structural-eq, which it only can be if you derive several traits on it. It doesn't need to be structural-eq recursively, so we can just manually implement the relevant traits on the pattern type and use the pattern type as a private field.

Waiting on:

* [x] move all unrelated commits into their own PRs.
* [x] fix niche computation (see 2db07f9)
* [x] add lots more tests
* [x] T-types MCP rust-lang/types-team#126 to finish
* [x] some commit cleanup
* [x] full self-review
* [x] remove 61bd325, it's not necessary anymore I think.
* [ ] ~~make sure we never accidentally leak pattern types to user code (add stability checks or feature gate checks and appopriate tests)~~ we don't even do this for the new float primitives
* [x] get approval that [the scope expansion to trait impls](https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/Pattern.20types.20types-team.23126/near/427670099) is ok

r? `@BoxyUwU`
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Apr 18, 2024
Implement minimal, internal-only pattern types in the type system

rebase of rust-lang/rust#107606

You can create pattern types with `std::pat::pattern_type!(ty is pat)`. The feature is incomplete and will panic on you if you use any pattern other than integral range patterns. The only way to create or deconstruct a pattern type is via `transmute`.

This PR's implementation differs from the MCP's text. Specifically

> This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.

is violated in this PR. The reason is that we do need impls after all in order to make them usable as fields. constants of type `std::time::Nanoseconds` struct are used in patterns, so the type must be structural-eq, which it only can be if you derive several traits on it. It doesn't need to be structural-eq recursively, so we can just manually implement the relevant traits on the pattern type and use the pattern type as a private field.

Waiting on:

* [x] move all unrelated commits into their own PRs.
* [x] fix niche computation (see 2db07f94f44f078daffe5823680d07d4fded883f)
* [x] add lots more tests
* [x] T-types MCP rust-lang/types-team#126 to finish
* [x] some commit cleanup
* [x] full self-review
* [x] remove 61bd325da19a918cc3e02bbbdce97281a389c648, it's not necessary anymore I think.
* [ ] ~~make sure we never accidentally leak pattern types to user code (add stability checks or feature gate checks and appopriate tests)~~ we don't even do this for the new float primitives
* [x] get approval that [the scope expansion to trait impls](https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/Pattern.20types.20types-team.23126/near/427670099) is ok

r? `@BoxyUwU`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
finished-final-comment-period The FCP has finished, action upon the disposition label needs to be taken major-change A major change proposal major-change-accepted An accepted major change proposal T-types Add this label so rfcbot knows to poll the types team to-announce Announce this issue on triage meeting
Projects
None yet
Development

No branches or pull requests

3 participants