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

Tracking issue for RFC #2175: or-patterns in if / while let expressions #48215

Closed
3 tasks done
aturon opened this issue Feb 14, 2018 · 29 comments
Closed
3 tasks done

Tracking issue for RFC #2175: or-patterns in if / while let expressions #48215

aturon opened this issue Feb 14, 2018 · 29 comments
Assignees
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Feb 14, 2018

This is a tracking issue for the RFC "or-patterns in if / while let expressions" (rust-lang/rfcs#2175).

Steps:

@aturon aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Feb 14, 2018
@zackmdavis
Copy link
Member

This seems likely to be a rather straightforward change: currently parse_arm calls parse_pats to parse the |-separated patterns of a match arm, whereas parse_if_let_expr just calls parse_pat.

I'd like to take this.

@zackmdavis
Copy link
Member

Arguably we should retitle the issue and RFC to make it clear that the ultimately approved proposal actually includes let itself (in addition to if let and while let).

@zackmdavis
Copy link
Member

This seems likely to be a rather straightforward change: currently [...]

Er, this remark was terribly naïve: the change to the parser might be that simple, but then the IfLet (&c.) AST nodes have to hold a vector rather than a single pattern, and much of the code that handles them (e.g., HIR lowering) needs to change correspondingly.

@nikomatsakis
Copy link
Contributor

@zackmdavis

Er, this remark was terribly naïve: the change to the parser might be that simple, but then the IfLet (&c.) AST nodes have to hold a vector rather than a single pattern, and much of the code that handles them (e.g., HIR lowering) needs to change correspondingly.

Sounds about right. but it should still be something that can be done purely in HIR lowering, right? I would think so.

@zackmdavis
Copy link
Member

something that can be done purely in HIR lowering, right?

Visitors, pretty-printing, and resolution are also affected.

@nikomatsakis
Copy link
Contributor

Sounds about right. I guess what I meant is "after HIR lowering, I wouldn't expect much other code to care"

@zackmdavis
Copy link
Member

(I was actively working on this today, but would seem to have been pre-empted by #48490.)

Manishearth added a commit to Manishearth/rust that referenced this issue Feb 24, 2018
Implement multiple patterns with `|` in `if let` and `while let` (RFC 2175)

cc rust-lang#48215
@dtolnay
Copy link
Member

dtolnay commented Mar 31, 2018

Does optional leading vert need to be supported here for consistency with #44101?

if let
    | A(x)
    | B(x) = expr
{
    /* ... */
}

@mdinger

@mdinger
Copy link
Contributor

mdinger commented Apr 1, 2018

@dtolnay

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 match definitely is a benefit.

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.

@mdinger
Copy link
Contributor

mdinger commented Apr 1, 2018

Also, the RFC grammar should be updated to reflect this change.

@Centril
Copy link
Contributor

Centril commented Apr 7, 2018

I concur with @mdinger, the intention of the RFC was to increase uniformity and consistency.

@Centril
Copy link
Contributor

Centril commented Apr 7, 2018

@petrochenkov The let Ok(x) | Err(x) = foo; part has not been implemented yet, right?

@petrochenkov
Copy link
Contributor

@Centril
No, | in if let and while let is simple desugaring, but | in let is pretty much equivalent to full rust-lang/rfcs#1882 as I understand it.

Does optional leading vert need to be supported here for consistency with #44101?

I didn't implement it only because it required an extra flag in AST for feature gating, now leading | is stable so it can be added trivially.

@Centril
Copy link
Contributor

Centril commented May 11, 2018

@petrochenkov So I forgot to say that | in let is only permitted at the top level with the RFC as written; it does not amount to full rust-lang/rfcs#1882, so the following would still be illegal with this RFC:

let (None | Some(_), None | Some(_)) = (None, None);

@alexreg
Copy link
Contributor

alexreg commented May 11, 2018

@Centril 😞 Still, better than nothing!

@Centril
Copy link
Contributor

Centril commented Sep 10, 2018

Update: rust-lang/rfcs#2530 was accepted to extend this RFC to for loops and optional leading vert.

@Centril
Copy link
Contributor

Centril commented Oct 7, 2018

I'm closing this issue in favor of #54883 to track all those changes since rust-lang/rfcs#2535 subsumes RFC 2175.

@petrochenkov
Copy link
Contributor

Reopening because the implemented feature if_while_or_patterns still points to this issue.
Nothing prevents passing this subset through stabilization before the larger #54883 is implemented.

@petrochenkov petrochenkov reopened this Nov 1, 2018
@petrochenkov
Copy link
Contributor

@Centril
Could you start an FCP for stabilization?

The feature was implemented in #48490 as trivial desugaring into match, that PR also has tests.

@Centril
Copy link
Contributor

Centril commented Nov 1, 2018

@petrochenkov the let Ok(x) | Err(x) bits and the changes in rust-lang/rfcs#2530 are not implemented as far as I know, both of which are part of RFC 2175 + amendment.

@petrochenkov
Copy link
Contributor

petrochenkov commented Nov 1, 2018

@Centril
As I said in one of the previous comments, let Ok(x) | Err(x) is a complex feature equivalent to full #54883, and the leading vert can be added in the stabilization PR or later, it's not a blocker/back-compat concern.

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.

@Centril
Copy link
Contributor

Centril commented Nov 1, 2018

@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 let Ok(x) | Err(x) = ... was a requirement to accept 2175... But the team is in agreement to go much further; so I don't know. I will defer to Niko here (or someone who has been in @rust-lang/lang longer than me...).

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Nov 2, 2018

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 :

  • What behavior is being stabilized
  • How this deviates from the RFC (it it does)
  • What unresolved questions are being resolved through this stabilization
  • What behavior is NOT being stabilized
    • and why
  • Test cases for all of the above

A good example where we did this "staged stabilization" was for the ? in main RFC. If you check out the tracking issue #43301 you will see that it has a section called "Stabilizations", which lists two sub-issues:

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 :)

@Centril
Copy link
Contributor

Centril commented Nov 2, 2018

@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.

@petrochenkov
Copy link
Contributor

Ok, will do.

@Centril
Copy link
Contributor

Centril commented Nov 25, 2018

Proposed in #48215.

@glaebhoerl
Copy link
Contributor

@Centril You mean #56212 😛

@Centril
Copy link
Contributor

Centril commented Nov 25, 2018

@glaebhoerl hihi =P // blames copy buffer

@Centril
Copy link
Contributor

Centril commented Jan 12, 2019

Stabilization happened in #57532.
Documentation issue: rust-lang/reference#505

The remaining work is tracked in #54883.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants