-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for RFC #2175: or-patterns in if / while let expressions #48215
Comments
This seems likely to be a rather straightforward change: currently I'd like to take this. |
Er, this remark was terribly naïve: the change to the parser might be that simple, but then the |
Sounds about right. but it should still be something that can be done purely in HIR lowering, right? I would think so. |
Visitors, pretty-printing, and resolution are also affected. |
Sounds about right. I guess what I meant is "after HIR lowering, I wouldn't expect much other code to care" |
(I was actively working on this today, but would seem to have been pre-empted by #48490.) |
Implement multiple patterns with `|` in `if let` and `while let` (RFC 2175) cc rust-lang#48215
I would argue yes because examining a large number of cases in that fashion would be advantageous over non-prepended verts (assuming you prefer the style). Maintaining consistency with Additionally, I wouldn't expect many downsides to this. The main ones would be a complexity increase, dislike from people who disapprove of the style, and perhaps macro particulars being more complicated. |
Also, the RFC grammar should be updated to reflect this change. |
I concur with @mdinger, the intention of the RFC was to increase uniformity and consistency. |
@petrochenkov The |
@Centril
I didn't implement it only because it required an extra flag in AST for feature gating, now leading |
@petrochenkov So I forgot to say that let (None | Some(_), None | Some(_)) = (None, None); |
@Centril 😞 Still, better than nothing! |
Update: rust-lang/rfcs#2530 was accepted to extend this RFC to |
I'm closing this issue in favor of #54883 to track all those changes since rust-lang/rfcs#2535 subsumes RFC 2175. |
Reopening because the implemented feature |
@petrochenkov the |
@Centril My goal here is to stabilize this occasionally useful feature now, and not delay its stabilization on larger implementation work required to support its extensions. |
@petrochenkov being the new kid on the lang team block, I'm unsure as to whether we are OK with stabilizing parts of RFCs or whether we require them to come in units... In particular, @nikomatsakis noted in RFC 2175 that |
I think it's fine to stabilize part of an RFC, we do it all the time. What I would recommend is that we open up a new issue dedicated to the stabilization (this is what we should always do, in my opinion). The issue header can describe clearly :
A good example where we did this "staged stabilization" was for the
Those issues are examples of the kind of report I would like to see (I did them myself, so asking for anything more would be somewhat hypocritical I suppose :) |
@petrochenkov could you write up a report per #48215 (comment) in a new issue (or PR at your option...)? I'll fcp merge that :) I'd like the stabilization PR to include leading vert at least also. |
Ok, will do. |
Proposed in #48215. |
@glaebhoerl hihi =P // blames copy buffer |
Stabilization happened in #57532. The remaining work is tracked in #54883. |
This is a tracking issue for the RFC "or-patterns in if / while let expressions" (rust-lang/rfcs#2175).
Steps:
The text was updated successfully, but these errors were encountered: