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

MCP: Deref Patterns #77

Closed
chorman0773 opened this issue Jan 14, 2021 · 13 comments
Closed

MCP: Deref Patterns #77

chorman0773 opened this issue Jan 14, 2021 · 13 comments
Labels
disposition-merge The FCP starter wants to merge (accept) this finished-final-comment-period major-change Major change proposal T-lang to-announce Not yet announced MCP proposals

Comments

@chorman0773
Copy link
Contributor

Proposal

Allow pattern matching through types that impl Deref or DerefMut.

Summary and problem statement

Currently in rust, matching is blocked by bounderies like smart pointers, containers, and some wrappers. To solve this problem you would need to either use if let guards (unstable), or nested match/if-let. The former is limited to one such level, and the latter can become excessive for deeply nested types. To solve this, I propose that "deref patterns" be added, to allow for such matching to be performed.

An exception to the above problem, is that Box<T> can be matched with feature(box_patterns). However, this is magic behaviour of box, and I am not a fan of this kind of magic.

Motivation, use-cases, and solution sketches

Recursive types necessarily include smart pointers, even when you could normally match through them.
For example, in a proc-macro I worked on to support restricted variadic generics, I wanted to match "fold expressions", which take the form (<pattern> <op> ...), so I would need to match against Expr::Paren(ParenExpr{expr: Expr::Binary(ExprBinary{ left, op, right: Expr::Verbaitum(t), ..}), ..}). However, this is currently not possible, and required nested matches. This generalizes to any case where you need to check some pattern, but hit a deref boundery.

Prioritization

I do not believe this fits into any of the listed priorities. It may be considered "Targeted ergonomic wins and extensions", however, I believe it is a larger than is intended for the category.

Links and related work

This has been discussed on the Rust Internals Forum at https://internals.rust-lang.org/t/somewhat-random-idea-deref-patterns/13813, as well as on zulip at https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deref.20patterns.

A tracking document of all currently discussed questions and potential answers can be found here https://hackmd.io/GBTt4ptjTh219SBhDCPO4A.

Prior discussions raised on the IRLO thread:

Initial people involved

I would be involved initially, as well as Nadreiril on zulip. I would be open to anyone who wished to helping with it.

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.

@chorman0773 chorman0773 added T-lang major-change Major change proposal labels Jan 14, 2021
@rustbot
Copy link
Collaborator

rustbot commented Jan 14, 2021

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 rustbot added the to-announce Not yet announced MCP proposals label Jan 14, 2021
@joshtriplett
Copy link
Member

We discussed this in the 2021-01-19 @rust-lang/lang meeting. We were generally in favor; we're currently figuring out who may be able to serve as the liaison for this. @scottmcm volunteered to work with the proposers to prepare for a lang design meeting.

@scottmcm
Copy link
Member

I have not idea what the right solution is, but the problem space is persuasive, so I support chartering a team to explore it and figure out a good way forward here.

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jan 19, 2021
@scottmcm
Copy link
Member

We discussed this in triage today.

Are you willing to lead this, @chorman0773? We're open to a group here, if you'd like to post a PR with a charter and membership.

@chorman0773
Copy link
Contributor Author

I would be willing to lead the project. I will look into the procedure to file such a PR.

@nikomatsakis
Copy link
Contributor

Per our last meeting, i am going to fcp merge this charter. Looks great, thanks @chorman0773 for the iteration!

@rfcbot fcp merge

@nikomatsakis
Copy link
Contributor

Hmm, is rfcbot ... active here?

@nikomatsakis
Copy link
Contributor

@nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

@nikomatsakis
Copy link
Contributor

well we can do it by hand for now

@rfcbot
Copy link
Collaborator

rfcbot commented Feb 26, 2021

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period disposition-merge The FCP starter wants to merge (accept) this and removed proposed-final-comment-period labels Feb 26, 2021
@rfcbot
Copy link
Collaborator

rfcbot commented Mar 2, 2021

🔔 This is now entering its final comment period, as per the review above. 🔔

@nikomatsakis
Copy link
Contributor

Closing -- project created #88

@rfcbot rfcbot added finished-final-comment-period and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Mar 12, 2021
@AlbertMarashi

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge The FCP starter wants to merge (accept) this finished-final-comment-period major-change Major change proposal T-lang to-announce Not yet announced MCP proposals
Projects
None yet
Development

No branches or pull requests

7 participants