Pattern types

[oli-obk]

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:

• [x] 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.

[rustbot]

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

[BoxyUwU]

@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